The short version
- Software built inside an agency either has its users on the payroll or has to go and find them. That is decided long before launch.
- We shipped a product with payments and fulfilment integrated. Nothing about it was broken and it earned nothing across its entire life.
- The builds that stuck had their users inside the business: a 255-page content engine, a publish gate over 44 pages, a portal per client.
- Engineers on staff make a build look cheap. It is cheap to start and no cheaper to maintain, so the build or buy test runs before anyone estimates.
Software built inside a services business arrives with one of two user bases: the delivery team, already there every day, or strangers who have to be found. We have built both. The first kind had its users before it had a first version. The second went live, worked, and earned nothing across its entire life.
What does a services business give a product?
A problem watched from inside somebody else’s company, repeatedly. Across 8 client accounts, 11 brands and 5 verticals the same gaps turn up often enough to stop being anecdote.
It also pays for the build. What it does not hand over is a channel: client work arrives through relationships and referrals, and neither of those turns into a signup flow.
What we have built inside the agency, and where its users came from:
| What we built | Scope | Its users | Channel needed? |
|---|---|---|---|
| Programmatic content engine | 255 pages | Our delivery team | No |
| Automated publish gate | 44 pages | Writers on that account | No |
| Newsletter QA gate | Issues 20 to 30 | The editorial team | No |
| Per-client portals | One per client | Clients we already had | No |
| Standalone product | Payments and fulfilment live | Strangers | Yes |
Why did our standalone product earn nothing?
Because we answered every question except how the first hundred people would arrive. Designed, built, payments and fulfilment integrated, live. That question got deferred to launch, where it turned out to need months of lead time rather than a day.
Nothing was broken. The thing worked and earned nothing for its entire life. Services had trained us out of seeing the gap, because in services the channel is a conversation somebody else already started.
What does the product take from the client work?
Attention, the one input the two sides cannot share. An hour on the roadmap is an hour off an account, and accounts run on a weekly cadence that does not pause for a product decision. Client calls sit on a Monday or a Tuesday and become action items on the Wednesday. Product work fits into what is left.
The bias is the second cost. Three of our team are AI engineers, so a build always looks cheap from inside. It is cheap to start and no cheaper to maintain, so the test runs before anyone estimates: buy when the workflow is standard across companies, build when it exists only because of your own product.
Which software is worth building inside an agency?
The kind whose users are already on the delivery team, which removes the failure that killed the product. A publish gate encoding one client’s editorial rules has no vendor, and the people who need it wrote the rules.
Client portals work the same way. Each client sees a page carrying only their own work, and every user of that software had signed a contract with us before the software existed.
We integrated payments and fulfilment into a product that earned nothing, because the one question we deferred to launch was the only one that decided the outcome.
What would we do differently?
Put the first hundred users in the build plan, with an owner and a date, alongside the features. If the honest answer to how they arrive is that people will find it, there is no plan.
And start from work somebody is already doing by hand. The newsletter QA gate exists because the same editorial notes were being given twice, and the 44-page validator went in after the fact, which is the normal order and the expensive one. The one thing that started from a market opportunity is the one that earned nothing.
Longer versions of both: the full account of the product that earned nothing and the build or buy test in detail.
Frequently asked questions
Can a marketing agency build its own software?
Yes, and the version that works ships to users who are already inside the business. Ours includes a 255-page content engine, a publish gate over 44 pages, a QA gate behind eleven newsletter issues, and a portal per client. Every one of them had users on day one.
Why do agency-built products fail?
Distribution. Agency work arrives through relationships, so an agency rarely owns a channel that reaches strangers. We shipped a product with payments and fulfilment integrated and it earned nothing across its entire life. Nothing was broken and nobody arrived.
What is the difference between internal tooling and a product?
Who has to be found. Internal tooling ships to a team already doing the work by hand, so adoption is the same conversation as the build. A product ships to people who do not know it exists.
Should an agency build its tools or buy them?
Buy when the workflow is standard across companies, because funded vendors compete on those. Build when it exists only because of how your own product works. A publish gate encoding one client's editorial rules has no vendor. A CRM has plenty.
How do you protect client work while building a product?
By fixing where the client conversations sit. Every client call we run lands on a Monday or a Tuesday and becomes action items midweek, which leaves the rest of the week able to hold a problem that has to stay in your head.
Is turning an agency into a software company a good idea?
The agency supplies the problem and pays for the build. It supplies no channel, and that is the gap to close before writing code. Every tool we built for our own delivery team had users waiting. The one product that needed strangers earned nothing.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
