Back to all posts

Building A-du · Part Eight: A-du Build

Building A-du: Part Eight

Chris Koss, AIA|Published May 20, 2026|Last updated May 29, 2026

What 'verified vendor' actually means on A-du Build. Architect, engineer, and contractor licensing fields, a real bid lifecycle, and the workflow underneath the marketplace.

The problem

The marketplace half of building an ADU is already a confusing place. Pick the wrong architect, you'll spend months redesigning. Pick the wrong engineer, you'll spend months in plan check. Pick the wrong general contractor, you'll spend months, and considerably more money, recovering. Most homeowners I've talked to have no good way to evaluate any of those choices, because the people they're choosing between don't have a consistent way to show their qualifications, and the homeowner doesn't have a consistent way to check.

I wanted A-du Build to be the place where that asymmetry stops. Not because we're picking winners (we aren't), but because the platform should make the relevant facts visible, comparable, and honest, so the homeowner can make a real decision.

That's harder than it sounds. "Verified vendor" is a phrase that gets thrown around loosely on a lot of marketplaces, and it usually means "we checked the email address." On a project that involves a real building permit, real money, and real safety implications, the bar should be higher.

What we built

Every vendor on A-du Build has a profile with a clear set of licensing fields. Architects have a California architect license number. Engineers have a structural or civil engineering license number. General contractors have a CSLB license. Those numbers aren't decorative. They're the basis for the verification we do before a vendor can take work through the platform.

We don't ask for proof of qualifications and then forget about it. The licensing fields are part of the vendor's profile, they show up alongside their work in the marketplace, and they're referenced when a vendor is invited to bid on a project. A homeowner browsing vendors sees the same information about each one, in the same place, in the same format. There's no asymmetric self-reporting where one vendor's profile is hand-decorated with credentials and another's is a wall of text.

Then there's the bidding workflow.

When a homeowner is ready to move forward on an ADU project, they don't have to track down vendors one by one. The platform runs a real bidding flow:

  • The homeowner initiates a bid request from inside the platform, describing the project and selecting candidate vendors (or asking us to surface the right ones).
  • Each invited vendor gets the request, can see what's being asked for, and submits a structured bid (scope, timeline, cost) back through the platform.
  • The homeowner sees the bids side by side, in a comparable format, with the vendor's profile and licensing visible alongside.
  • The homeowner selects a bid. The other vendors are notified. The accepted vendor's bid converts into the active job.

That whole sequence used to live in a chain of email attachments. On A-du Build, it lives in a workflow with state. The homeowner can see the status of their request. The vendors can see whether their bid is still in play. Nobody is left wondering whether their email got buried.

A related piece, and this is the part where A-du Build genuinely earns its keep, is the permit fee workflow. Permitting an ADU involves real fees paid to the municipality, and those fees get paid through the contractor or the permit-pulling vendor, not directly by the homeowner. Without a platform, the way that usually works is the contractor gives you a number, you write them a check, they pay the city, and you trust them to pass the receipts back. On A-du Build, the vendor proposes the permit fee through the platform, the homeowner pays through Stripe, and the platform tracks the payment lifecycle (proposed, paid, completed) visibly to both sides. There's no question about whether the fee was paid or how much it was.

A small, related thing: build jobs on A-du have a real status machine. "Pending bids," "in design," "in plan check," "under construction," "complete." The platform tracks them so the homeowner doesn't have to ask the contractor for a status update every two weeks, and the vendor doesn't have to repeat themselves to a worried homeowner every two weeks.

What it means for you

If you're a homeowner planning an ADU, A-du Build gives you a real comparison surface. You can see vendors' licensed credentials in a consistent format, request and compare bids through the platform, pay permit fees with a receipt and a clean lifecycle, and watch the project progress through real status, not vibes.

If you're a vendor (architect, engineer, contractor), A-du Build gives you visibility for the work you've done, a real pipeline of projects, and a structured bidding flow that doesn't require you to re-explain yourself in an email thread six times. Your licensing is presented honestly. Your work is presented in the same format as everyone else's. Vendor profiles and listings on A-du Build are free to set up.

And on the homeowner side: uploading a pre-approved or vendor-created plan to A-du Build is free. No listing fees, ever, on plan uploads.

What I learned

The first lesson is that "trust me" doesn't scale. A single-vendor relationship can survive on personal trust. A marketplace cannot. The way you replace personal trust at scale is with consistent, comparable, verifiable information, presented the same way to everyone. License fields are the boringest version of that, and they do most of the work.

The second lesson is about the bid lifecycle specifically. There's a temptation when you're building a marketplace to leave the deal-shaping work to the parties: "we'll just connect you, you work it out." That's a mistake. The deal-shaping is where the value is. If the platform doesn't track which bids are active, which have been accepted, and which have been rejected, the platform isn't really a platform; it's a directory with contact info. Building the bid lifecycle as a real, stateful workflow is the difference.

The third lesson, and this one connects all the way back to the architect's lens I mentioned in the prelude, is that building an ADU is more like building a small civic project than building a piece of consumer software. There are real permits, real licensed professionals, real safety codes. The platform's job isn't to abstract those things away. It's to make them legible. Licensing fields, bid status, permit fee lifecycle: those are all just ways of making real-world seriousness visible.

Next in the series: how A-du Manage seeds a services marketplace by scraping local businesses, and why we built the claim flow before we built the lead flow.