There is no shortage of developer content on the internet.

Tutorials. Framework announcements. AI news. "10 things you should know." Another explanation of how to build a todo app with whatever library launched this week.

That content has its place.

But it is not what this site is for.

Built in Production is about what happens after the demo works.

It is about the decisions, tradeoffs, mistakes, systems, and lessons that come from building software people actually use.

That means writing about the parts of engineering that are usually messier than the final architecture diagram suggests.

The feature that looked simple until real users touched it. The model that performed well in testing but behaved differently in production. The refactor that fixed one problem and introduced another. The monitoring you wish you had added earlier. The architecture decision that seemed wrong at first but turned out to be the right call. The code that was technically correct but still produced the wrong product experience.

Those are the stories I want to write about here.

Less theory. More reality.

Most engineering decisions are not made with perfect information.

You have constraints. You have deadlines. You have users asking for things. You have systems that already exist. You have technical debt. You have a bug that only happens in production. And sometimes the "best" technical solution is not actually the best solution for the product.

That is the side of software development I find most interesting.

How does this technology work?
What happens when you actually try to use it?

That distinction matters even more now that AI is becoming a normal part of software development.

It is easy to build an impressive AI demo. It is much harder to make that demo reliable, observable, fast, affordable, understandable, testable, and useful to real people.

The gap between those two things is where a lot of interesting engineering happens.

What I will write about

AI Engineering

Not AI news. Not model leaderboard commentary. The practical side of building AI into products.

  • evaluations, agents, and structured outputs
  • realtime systems and prompt design
  • model tradeoffs, latency, and reliability
  • observability, deterministic logic, and debugging AI pipelines

I am especially interested in the difference between an AI feature that works in a controlled test and one that survives production.

Software Engineering

Architecture decisions, APIs, databases, refactors, debugging, infrastructure, performance, and the implementation details that only become obvious after shipping.

Product Engineering

Developers do not build software in isolation. A technically elegant system that does not solve the user's problem is still the wrong system.

I want to write about interpreting user feedback, deciding what to build, simplifying workflows, prototyping, technical debt, shipping quickly without creating chaos, and knowing when not to build something.

Postmortems

What broke? Why did it break? Why did the original design seem reasonable? How did we find the problem? What changed afterward? Not every failure needs to be dramatic. Sometimes the most useful engineering lessons come from surprisingly small mistakes.

I do not want this to become another tutorial site

There will probably be code here. There will be technical walkthroughs. There may even be tutorials occasionally. But the goal is not to publish articles that could have been generated from documentation.

I am much more interested in writing that starts like this:

We tried this. It worked. Then it stopped working. Here is why.

Or: We originally built it this way. After seeing how people actually used it, we realized the architecture was wrong.

Or: Everyone assumed the AI model was the problem. It was not.

That is the kind of engineering knowledge that tends to stick.

Writing from the middle of it

I am not writing this as someone who has finished learning how software should be built. Quite the opposite. A lot of these posts will be written while I am still figuring things out. That is intentional.

There is value in writing down how you currently think about a problem before hindsight turns everything into a clean story. I want to document decisions while the tradeoffs are still visible: what I believed, what I tried, what failed, what changed my mind, and what I would do differently now.

Maybe six months later I will disagree with something I wrote. That is fine. Software changes. Tools change. Models change. Experience changes your opinions. The point is not to always be right. The point is to understand why we made the decisions we made.

Eventually, I want this to be bigger than one developer

For now, Built in Production will mostly be my writing. But I like the idea of this becoming a place where other developers share their own production stories too.

Not polished corporate engineering posts where everything went according to plan. The useful stuff: the strange bug, the failed migration, the architecture you regret, the system you rebuilt, the shortcut that worked, the shortcut that definitely did not, and the thing you learned after the tenth customer used the feature differently than you expected.

There are a lot of good engineering stories hiding inside companies that never get written down. I would like this to become a place for them.

So, welcome

Built in Production is an experiment. A place to think in public about software, AI, products, systems, and everything that happens between writing the first line of code and running something in production.

If that sounds interesting, stick around. There should be plenty to write about.

STATUS / INITIALIZED