Product and growth engineering

Each feature starts as a written spec with rules every build must follow: add to what works and never rewrite it, leave sign-in and attribution alone, check each column name against the live database. An AI app builder, driven by a coding agent over MCP, writes the change; the exact change, the diff, comes back to me, and nothing goes live until it reads clean.

On a stealth biotech startup's member app, my review of all 36 builds caught rewrites that would have lost a user's first change, two builds writing to database columns that did not exist, saves using the sign-in ID where the database expected the profile ID, and links between tables that would have blocked account deletion. The app went from an empty database to production in one month, with a 14-field intake, a progress dashboard, a calendar on a unit-tested dosing model, data export and account deletion.

An AI agent writes each change to the database as a numbered script, a migration, and a parser reads each one before it runs, so a script that does not parse never reaches the database. Every table gets row-level security, so the database checks each read and write against the user making it. Functions with extra rights are locked down, a trigger stops members writing to fields reserved for admins, and admin actions are logged. The views shared with partners hide identities and show no figure for a group of fewer than five people.

Before launch I audit the live database read-only and rank what I find. On the stealth biotech startup's database that was three high and three medium findings, each closed with a staged fix script and a check that the fix held.

When your team edits the site itself, an AI agent builds the pages and templates from your brief, brand and content inside Framer, Webflow or WordPress, through their MCP servers and APIs, and writes the custom parts as React components. When the site has to sign people in, save what they do or build pages from your data, it is a Next.js app on Vercel, with its DNS on Cloudflare and a Postgres database, so the site and your product share one record.

I review each page before it goes live, and the move changes only the DNS record that points your domain at the new host, so your email and the rest of your domain keep running. For a stealth biotech startup I rebuilt the marketing site in Framer in ten days for a conference deadline: 8 pages and 31 custom React components, with no downtime when the domain moved.

As each post arrives, a low-cost model reads it into fixed fields (item, price, place, contact) and scores how sure it is. A post it scores below the confidence level you set goes to a stronger model, and one still below that level waits for a person.

After that it is all code: the listing is validated, saved in Postgres and placed on the map or in the feed. Most posts need only the low-cost call, which keeps the cost low enough to read every post your channels receive.

Your app sends each event to a table that can only be added to, tied to the signed-in user, or before signup to an anonymous ID. That ID links a visitor's visits before signup to the member after it, the source tag on the first link carries into the signup and every event after it, and the app sends events in batches and saves them when the page closes.

Partners and analysts read a version with identities hidden behind hashed keys instead of the raw table, and an attribution view shows what each first link brought, counting a member as active 30 days after signup when they recorded an event in the seven days before. For the stealth biotech startup it tracked 54 types of event.

Each email carries a tracking pixel for opens, and each link goes through a redirect that records the click and adds a campaign tag, so GA4 credits the visit to the email. The events are stored in Cloudflare R2.

Company security scanners open the links in an email within seconds of sending, from a data centre. Code spots them by that timing and that network and keeps them out of the counts. Opens stay a rough signal, since some mail apps load every email's pixel on arrival, so a campaign is judged on its clicks.

Code fills in each record you send (a lead, a company, a contact) from public sources and tags each field with its source, and a model decides which records across sources describe the same one. An email address is judged on where it was seen in public, what its mail server answers when asked whether the mailbox exists, and whether it fits the domain's address format, since some servers accept any address.

Each field gets a grade: verified when a primary source confirms it, likely when sources agree, unverified otherwise. Your outreach, your CRM and your reports read only the grade they need, and an address that fails the check stops a send.

Each source (supplier feeds, exports, scraped pages, APIs) has its own connector that runs on a schedule. Python converts the units, currencies and names into one format in Postgres, and code works out the price changes by competitor, product and region from it.

You ask a question, such as which competitor cut prices in a region this month, and a model writes the database query, runs it read-only and answers with the rows behind it. A new source means one new connector, and nothing else changes.

Queries run on a schedule against GA4, Mixpanel or the events in Postgres. Code works out what changed against the week before and your targets, a model writes it up, and a check rejects any figure in the summary that does not match its query's result.

The summary is sent to you each week, and the charts sit on a dashboard behind a login.