Building an AI Native Company

Most software companies add AI. A few are built on it. Recipe2Kitchen is the second kind. Not because it is cleverer, but because there is nobody here to do the loop by hand. I am the only person. If the loop stops, the company stops.

That constraint was the design brief. When you cannot be the one to write the post, read the support email, or ship the fix, you stop asking how to make your workflow more efficient and start asking what has to be true for it to run without me. The first produces autocomplete. The second produces a self operating system, and it is not harder to build. It is just less common.

A disclosure before the argument, since the subject is agents writing things: this article is one of them. I decided what it should say; an agent drafted it from that intent, and the sentences are a machine's reading of my argument. What I wanted made is not how good the app is to use, though it is genuinely good, but how the company behind it runs.

Here is the route. First, what AI native actually means, and the two principles that separate it from AI assisted work. Then the machinery: the stack, the daily post, the agent that watches, the fix loop, the knowledge agent, and what it costs to run. Finally, why none of it is difficult to copy, and what that means for anyone still doing this by hand.

What AI native means here

An AI native company has two defining principles.

The default path is autonomous. A person can intervene, but the system does not wait for one, and nothing is approved before it happens. If the agent cannot act, the work does not happen.

The agent owns the loop, not a step. Plenty of tools generate text. Fewer read the metrics afterwards, notice the number moved wrong, change the code, run the tests, and deploy. A generator without a feedback path is an expensive random number generator.

The stack is boring on purpose

The models are rented. What matters is that the scaffolding around them is conventional enough for a machine to reason about.

• TypeScript end to end, one language across app, API, and agent scripts. Types are a contract: when the agent changes a shape, the compiler says what it broke.
• Postgres for everything durable: recipes, users, posts, metric snapshots, a cost ledger. Agents handle sprawl badly and read a schema well.
• Fly.io to run it. Deploys that are a command, logs the agent can read.
• GitHub Actions for anything that is not an agent's job. A schedule is a schedule.
• OpenRouter for model access. One key, many models, and the ability to move a workload without rewriting the integration.
• Hermes Agent as the operating layer. It reads the email, pulls the metrics, writes the code, runs the tests, asks for a deploy. Not a feature of the product. The colleague.

Each piece was chosen for one reason: legibility. An agent does its best work where the seams are obvious and the feedback is fast.

A blog post every day, without a writer

A scheduled job wakes the agent, which picks a topic from a queue of ideas and gaps in coverage, pulls product context and prior posts, and writes. The post goes through the same pipeline as hand-written content: markdown, frontmatter, build, deploy. It appears in the app and on the site.

The part I care about is the control surface. The agent works against a written brief: voice rules, topics already covered, things not to say. When a post lands wrong, I change the brief instead of rewriting the draft. The correction compounds because it lives in the instructions, and instructions are the only thing that survives to the next run.

The agent that watches

On a schedule the agent collects email to the company addresses, classified and routed; app metrics including page views, signups, activation, error rates, and latency; cost telemetry per model call; and infrastructure health, meaning deploy status, failed runs, and the logs nobody reads when things are calm.

It writes that up as a report and sends it. The value is not that I read it every day, but that the agent has to look at everything in order to write it. Reporting is how the system pays attention. Cost gets its own line, since an agent that does not know its spend optimizes for activity over value.

When it finds a problem

Before editing anything, the agent explains the problem to itself in plain language: what changed, when, what the symptom looks like, the likely causes, and the smallest change that would test the hypothesis. Most automated fixes fail because the system skipped the step where it decided what the problem actually was.

Then it works the way a person would. Find the file that owns the symptom. Write a small, scoped change in the existing idiom. Run the tests, and where they do not exist, write them as part of the fix. Open a pull request with the reasoning, since the diff is the only artifact that lets me audit a decision later. Merge, deploy, and watch the metric that was broken.

Not every anomaly gets this treatment. Thresholds decide. A slow drift gets reported. A checkout returning errors gets fixed. The gate matters, because an agent that fixes everything breaks things politely.

When the problem is not code

Some issues do not have a commit as their remedy. Someone asks a question the documentation does not answer. A partner sends a request that needs a real reply. For those, a knowledge agent searches prior emails and how they were resolved, the docs, and the changelog. It reads the question as a person would and answers from what the system really does. When the honest answer is a real gap, the finding becomes an issue in the tracker instead of a reply that goes nowhere.

The split is about consequences rather than technology. A code fix is cheap to verify and reversible. Words sent to a customer are neither.

What this costs, and what it changes

The bill is small, per unit, and itemized. Every run carries a token cost and the agent tracks it against the work it produced. When a workload gets expensive, the fix is a cheaper model or a tighter prompt. Cost per unit is a design variable you control, not an accounting surprise you find out about later. Every post, reply, and fix has a price, and if you cannot measure it you are watching the business rather than running it.

The bigger change is what the company needs from me. Not my hours. My judgment, written down: what good looks like, what is out of bounds, when to stop and ask. My job is editing the brief and reading the report, which is the first time the limit on what this company can do is not how much time I have.

There is no reason to wait

Nothing in this stack is exotic. The models are rented by the token. The database, the host, and the pipeline are commodity. The agent is software I wrote and keep editing. There is no infrastructure team, no platform budget, and no twelve month roadmap between an idea and a company that runs.

That is the part I want to land. People talk about AI native as a bet on the future. It is available now, and the barrier is not capability or capital. It is the willingness to write down what good looks like and let a machine follow the instructions. Anyone running a small company can do this. I did, in the gaps between other work.

What this comes to

Recipe2Kitchen is one person plus an operating layer. The stack is ordinary and chosen for legibility. A scheduled agent writes the daily post against a written brief, and the brief is the real product. The same agent reads email, metrics, and cost, reports what it sees, and fixes what is broken by writing the code, running the tests, and shipping the deploy. Anything that is not code goes to a knowledge agent that answers from what the system actually does. Cost is small, visible, and measured per unit.

Two principles decide whether you have built this: the default path is autonomous, and the agent owns the whole loop. Hold both and the rest follows. The stack is commodity, the models are rented, and the only thing that is genuinely yours is the written judgment about what good looks like.

That description is not the test. The test is whether the thing works when I am not looking. Use it for free at recipe2kitchen.com. The posts land daily, the metrics get watched, the fixes ship. Watch for a week, judge for yourself, then go build your own. The tools are sitting there and the bill is smaller than most software subscriptions.