Perch is software for commercial construction: the system a general contractor uses to send a bid out to its subcontractors. This page is our plan for reaching the first hundred customers, and why it should compound after that.
First principles
Trust doesn't scale early, so don't try.
In a conservative, reference-driven industry, you win a few deeply before you win many. Every fast-growing vertical AI company did exactly this.
First customers build the product: they don't buy a finished one.
Co-development beats guessing. The fastest path to fit is sitting inside the customer's workflow and shipping against what you see.
In construction, your customers are your distribution.
Every bid a GC sends is an impression of Perch in front of hundreds of subs. The product itself is the channel.
A loop only works if the recipient transacts inside the product.
If a sub can respond to a bid outside Perch, the loop leaks. The strongest networks make using the product the only way through.
Never tax the people who spread you.
The side that fuels virality should feel served, not billed. Charge the side with budget; subsidize the side that carries you to the next account.
Two engines
Perch Partner Program
A small set of hand-picked GCs co-build the product with us in exchange for shaping it around their work, and become our first reference logos.
The Bid-Surface Loop
Each GC's bids seed subs onto Perch. Happy subs carry Perch to the next GC when they bid elsewhere. The network pulls in the next customer.
The Perch Partner Program
This is what makes the Built Exteriors arrangement repeatable with a GC we don't already know. With a friend, the relationship carries the trust. With a stranger, the structure carries it.
Pick
3–5 GCs who bleed from the problem, not "this looks cool." Pain over friendliness. The selection is the whole game.
Ask
Payment, system access, a weekly working session, a decision-maker in the room. The commitment is what filters out tourists.
Give
Dedicated build time, direct founder access, and features shaped to their workflow that generalize back to the platform.
Shape
Timebox it (60–90 days), one shared goal, clear lanes: we own the build; they own access, feedback, and the decision.
Convert
It ends in a paid contract, a reference, and a case study, written in from day one, not hoped for at the end.
Built Exteriors
Founder embedded, co-developing, $15k/mo. Proves the model works.
Zwick
Mid-size UT GC via Kris & Brock. Proves it works beyond a friend, and gives us a cold-ish reference.
A marquee GC
Bigger GC = more subs invited = a bigger viral seed. Land one once the program is proven.
Case file: Textura
A GC↔sub network in construction, built before us. The prize is real.
Construction payment network · est. 2006
Acquired by Oracle · $663MA shared GC↔sub network in construction can become enormous: over $1 trillion in payments processed, 800+ GCs, 200,000+ subs.
GCs mandated their subs onto the platform, and subs had to use it to get paid. Required-to-transact drove near-total adoption.
The reputation layer
The lever that turns the loop's cold 1% into something that compounds, and the moat underneath everything. The Carfax move: make the absence of a track record the red flag. A sub without a Perch history looks risky; a GC can't not check.
Claim, don't build
Pre-fill a sub's profile from activity we already see, so signing on means claiming something they own, and GCs come to expect a Perch record on everyone.
Flaunt the record
Verified wins are worth showing off, so subs bid through Perch and pull the new GC in to see the score. Reputation only pays where it's visible.
It's one bet wearing three faces: required-to-transact makes the record true, the true record is portable value the sub owns, and that portable value is what makes subs carry Perch to new GCs. The deepest verified track record on subs is also the moat a rival can't copy and a GC won't leave.
The metric that matters
Net-new activated accounts sourced from our existing customers' bid activity.
This is the loop working. Today we have no formal way to see it, so the first job is making it visible.
Do customers beget customers? How many new accounts each existing one generates.
The loop turns in weeks, not months. Loop B is paced by bid frequency. So the real lever is conversion, not the calendar.
Now / next
Instrument the bid surface. Tag every account at birth: which GC invited it, which sub referred it. We can't manage a loop we can't see.
Run the program with Zwick. The real test of whether the motion survives outside a friendship.
Design the sub experience to be required-to-transact and portable. Required, so the loop doesn't leak. Portable, so subs carry us to new GCs.