// build
Custom Software Built by the Team That Also Has to Market It
Two applications can pass the same code review and deploy from the same pipeline, and only one of them can be sold. The difference is not code quality. It is a short list of choices made in the first weeks, usually before anyone responsible for demand is in the room. In a design doc they read as implementation detail. They turn out to be distribution.
We build the product: the backend, the data model, the API, the application a customer signs into. The same team here works on demand generation, so those choices get argued about while they are still cheap to change.
Your public marketing surface belongs somewhere else, on the page covering what a stranger sees before they have an account. That is web development, a separate job with its own measure of success. Our measure on this one is narrow: shipped, and actually used.
Distribution decisions get made in build meetings
By the time a growth team discovers these, they are structural and expensive. Four we put on the table before the first line of code, because each one is cheap to decide now and costly to reverse later:
- Rendering strategy. If a page’s content only exists after hydration, any client that fetches JavaScript without executing it never sees it. Measurements by Vercel and MERJ found exactly that behaviour from OAI-SearchBot, ChatGPT-User, GPTBot, ClaudeBot and PerplexityBot. Choosing client-only rendering for anything a customer might link to is a marketing decision made by an engineer who was not told it was one.
- URL design. State kept in query parameters, opaque numeric ids, views that cannot be linked to. Every shareable thing in your product needs a stable, readable, permanent address, and retrofitting that after launch means breaking links people already have.
- Where the login wall sits. Documentation, changelogs, integration pages and templates put behind auth are invisible to every acquisition channel at once. Some of it genuinely must be private. Most of it is behind the wall because nobody asked.
- Whether the product emits events. A product that does not say what happened inside it cannot tell you which campaign produced a customer who stayed. We define those events with the people who will have to report on them, and ship them with the feature that emits them. A quarter later is too late.
None of this makes the software better as software. It makes it possible to sell, which is a different property and one that no purely technical review will catch.
What we build
Multi-tenant B2B applications. Internal tools that replace a spreadsheet and a standing meeting. APIs, and the integration work that connects your system to the ones your customers already pay for. Background jobs and data pipelines. The billing path, which is easy to leave until last and then discover is entangled with the permission model.
We work in whatever your engineers already maintain where that is workable, typically a typed language and a relational database. Novel infrastructure is a liability you inherit and we do not.
How an MVP stays an MVP
An MVP is not a small version of the finished product. It is one workflow taken seriously, end to end, with the deploy pipeline and the error tracking in place, and everything else deliberately absent. That discipline is unpopular in the scoping meeting and it is the reason the thing reaches users.
We would rather cut features than cut the deploy path, the tests around money and permissions, or the instrumentation. Those three are what make the next six months cheap.
Terms we hold to
The stack stays one your own engineers can maintain, and the repository and cloud account stay in your name from the first commit. Content your customers are supposed to find does not get rendered client-side. A fixed price quoted against a specification that does not exist yet has to price the unknown parts at zero. So we scope the work first, then tell you what we found. Sometimes what we found is that you should buy software instead of building it.
Adoption is the one thing we cannot promise. We can build something worth adopting and instrument it so you can see whether it was. The rest belongs to your market.
What you get
- The application itself, in your repository and your cloud account, with no runtime dependency on us
- A short architecture decision record for every irreversible choice, covering data model, tenancy, auth and hosting
- CI running the test suite, type checks and a migration dry run on every pull request, so a broken deploy fails before production
- A deploy path with a tested rollback, plus the runbook the on-call person will read at 3am
- Product events specified with whoever owns growth and shipped with the feature, not retrofitted a quarter later
- Server-rendered routes for everything a customer or a crawler could reach without logging in
- A handover session in which your engineers deploy and roll back themselves while we watch
How it runs
- 01
Separate the reversible from the irreversible
Most decisions can be changed later and do not deserve a meeting. A handful cannot. The data model, the tenancy boundary, how identity works and what is public get written down first. Those are the decisions that are expensive to undo once there are customers in the database.
- 02
Build one slice end to end
The first thing we ship goes from the signed-out page through auth, through the write path, to a deploy in your production environment. A vertical slice exposes the integration problems in week one instead of in the week before launch, when they cost the most.
- 03
Instrument while the context is fresh
Events get defined with the people who will have to report on them, and land with the feature that emits them. Instrumentation added after launch means the first months of real usage are unmeasurable, and that is the data you most want later.
- 04
Ship behind a flag and harden in production
Real traffic finds the pathological inputs that staging never will. Flags let us put the feature in front of a small group and watch the errors and the latency. A bad release then rolls back in one step, with no new deploy.
- 05
Hand over until you do not need us
Your engineers run a deploy, a rollback and a restore from backup with us in the room. A build is only finished when the team that owns it can operate it alone. Handover is where that ownership gets tested instead of assumed.
Questions we get asked
- Why would a growth firm be writing our backend?
- Because the two jobs keep colliding. Rendering strategy, URL design, what sits behind the login wall, whether the product emits usable events. Every one of those is an engineering decision with a direct effect on distribution. All of them are normally settled months before anyone responsible for demand is in the room. We are in the room because we are also the ones who will have to sell it.
- How is this different from your web development page?
- This page is the product itself. The backend, the data model, the API, the application a customer signs into. Web development is the public surface in front of it, where the KPIs are page speed and conversion rate. Usually different codebases, different people reviewing them, different definitions of done. We keep them as separate engagements so you can buy one without the other.
- Do we own the code?
- Yes, outright. It lives in your repository and your cloud account from the first commit, so there is nothing to transfer at the end. If we stopped work tomorrow you would have a system your own engineers can build and deploy. Any dependency on us that cannot be removed in an afternoon is a defect, and we treat it as one.
- What stack do you use?
- Boring, typed, and whatever your team can already maintain, which usually means TypeScript or Python with a relational database. If you have engineers, their stack wins unless there is a specific reason it cannot do the job. We will not choose something novel that leaves you unable to hire anyone who can read it.
- Can you take over a codebase somebody else wrote?
- Often, but we will read it first and tell you honestly whether it is worth continuing. Sometimes the correct answer is a rewrite of one subsystem and not the whole thing. Sometimes the codebase is fine and the real problem is that nobody can deploy it. We will not quote a rescue before we have read the code.
- How small can the first version be?
- Small enough that it reaches real users in weeks instead of quarters, which usually means one workflow done properly and everything else deferred. The risk worth guarding against is not a first version that was too thin. It is a first version carrying twelve half-finished features and no way to deploy any of them. That is the version we will argue you out of.
- Will you also market it?
- That is the point, but it is a separate decision and a separate engagement. You can take the build on its own and keep whatever demand team you already have. Nothing on this page is bundled with a marketing retainer. What you get either way is a product built by people who know what the distribution side will need from it.