// pillar
Build and AI
Nothing bought on this page will bring one extra person to your product. Demand is not here. Campaigns, rankings, citations and testing on pages that already exist belong to the growth and visibility hubs, and they answer to different numbers. MAP monitoring is a separate line again. The measure on this side is narrow: software in production, used by the people it was built for.
Five services sit under this hub and they end the same way. Pull requests in your repository, reviewed by your engineers, running in your production environment. What separates them is who the software is for.
Which of the five you are buying is rarely obvious from the brief. A brief that is currently one sentence usually holds two or three separate projects. “We want to add AI to the product”. “The app needs rebuilding”. Each has its own buyer and its own way of going wrong.
Prising them apart is the first thing that happens here, before anything is costed. Skip that step and one budget funds whichever piece is the most interesting to build. It gets measured against a number chosen for a different project.
Which of the five you need
- Software development. Buy this if the application a customer signs into does not exist yet, or exists and will not survive the next year of load. Backend, data model, API, the thing behind the login.
- Web development. Buy this if a stranger meets a page before they ever meet the product. The public surface: fast, crawlable, and built to turn a reader into an account.
- AI automations. Buy this if someone on your staff loses the same forty minutes every day. The work costing them will never be important enough to reach a roadmap. Internal only, and your customers never see it.
- AI integration. Buy this if a model belongs inside the product people already pay for. It then needs evals, cost accounting and a decided answer for the times it is wrong.
- Agentic integrations. Buy this if the system has to choose its own next step and then act somewhere the action has consequences. Permissions, dry-run, an audit trail and a stop button are the work. The model is the easy part.
Three of those have AI in the name and they are not interchangeable. The dividing question is who touches the output: your staff, your customers, or nobody, because the system acted on its own.
One case routes out of this hub entirely. It covers a prototype an AI coding tool already wrote, where the job is security, hardening and getting it live, not building it again. That is vibe-coded app launch, over in growth.
Why an engineering line sits inside a growth firm
The normal arrangement is two suppliers. One writes the software, one sells it, and the decisions that matter most fall in the gap between them. The gap is where you get a product with no linkable URLs and with documentation behind a login. It is also where no event stream tells you which channel produced a customer who stayed.
We do not have that gap, because there is no second firm. The people who will have to generate demand for the thing sit in the build review, while the decisions are still cheap to change. That is the whole argument for this line existing. It is also the part that makes us accountable. When a product ships and cannot be sold, there is nobody else in the room to point at.
What is true on all five
The engineering standard does not change with the service.
Work arrives as pull requests in your repository and your engineers review them. We work in the stack your team already maintains, where that is workable. No infrastructure gets introduced that nobody there can operate after we leave. Deploys, error tracking and the tests that cover money and permissions exist before feature work starts. Anything we ship emits the events that describe what it did, defined with the people who will have to report on them. And every engagement ends with a runbook, because a system only one supplier can operate is a system you do not really own.
What gets refused
A model where a database query would do the same job, faster, cheaper and with the same answer twice. Putting AI on the invoice is not worth making the output non-deterministic.
Scopes where the deploy path and the instrumentation are what gets cut to fit the budget. If the money only stretches to features, the honest counter-proposal is a smaller system built properly, and that is the one we will make.
“It worked in the demo” as a definition of launched. A demo meets one person who wants it to succeed. Production meets everybody else, at once, on hardware you have not tested.
Any arrangement that parks part of the running system in an account of ours. Leaving should cost you a handover meeting, not a rewrite.
A build where nobody can yet answer “how will we know this worked?”. We decline those. If the answer is still being settled in week three, the scope has no edge. A six-week project then turns into a permanent one by accident.
What you get
- A written scope naming what gets built, what is deliberately absent from version one, and the measure that decides whether it worked
- Code delivered as pull requests into your repository, reviewed by your engineers before anything merges
- A deploy pipeline, error tracking and tests around money and permissions, in place before feature work starts
- Product events defined with the people who will have to report on them, and shipped with the feature that emits them
- A runbook covering how to run it locally, how to deploy it, what fails first and what to do when it does
- Ownership of everything we write from the first commit, in your organisation, on your infrastructure
How it runs
- 01
Split the brief into engagements
Most briefs contain two or three projects wearing one name. Separating them early gives each part its own scope and its own measure. Otherwise one budget quietly funds whichever piece is most fun to build.
- 02
Agree what finished means
We write down the condition that ends the project before we write code. Without it, scope grows by a feature a week and nobody can say whether the thing succeeded, because success was never defined.
- 03
Build the path to production first
Deploys, error tracking, and the tests that cover money and permissions come before features. A team that leaves those until the end ships late and then cannot change anything safely, which is the expensive half of the mistake.
- 04
Ship into your repository
Work lands as pull requests your own engineers review. It keeps your team's knowledge of the system current, and it means the day we stop is not the day the code becomes unmaintainable.
- 05
Instrument, then hand over
The feature ships with the events that report on it and a runbook written for whoever inherits it. We would rather be removable than retained by obscurity.
Questions we get asked
- Why buy engineering from a firm that also does marketing?
- Because the decisions that make software hard to sell are made during the build, not after it, and by then they are structural. Rendering strategy, URL design, where the login wall sits, whether the product emits events at all. When the same team owns both sides there is no handover meeting where those get lost, and nobody else to blame when they are.
- We already have engineers. What are you for?
- Usually one of three things. A team that is strong and has never done this particular thing before. A build that has to happen alongside keeping the current product alive. A piece nobody internally wants to own. If none of those describe you, keep the money. We will say so on the call, before there is an invoice.
- Which of the five services do we actually need?
- The short version. The application behind your login is software development, and the pages in front of it are web development. Work your own staff repeats is AI automations. A model your customers touch is AI integration. A system that decides its own next step is agentic integrations. If two of them apply, they are still two engagements with two measures, and we scope them that way. Blurring them into one number helps nobody.
- Do we own the code?
- Yes, from the first commit. It lives in your repository, in your organisation, on infrastructure you control, with no runtime dependency on anything of ours. An agency that can only be replaced by rewriting its work has a commercial interest in you never looking too closely.
- Can you take over something built by someone else?
- Often, and we will read it before quoting. A prototype generated by an AI coding tool is a specific case with its own page under growth. The work there is security, hardening and launch, and not a new build. What we will not do is agree to inherit a system, discover it is unworkable, and then bill you to find that out.
- Can you commit to a fixed date?
- On a scope that is genuinely fixed, yes. On a scope still being discovered, a date is a guess wearing a suit. The honest answer is a first slice with a date and a decision point after it. A quarter-long timeline offered in a first call is priced against a system nobody has read yet.