Insights
Notes from Nieuw Solutions on AI agents, shipping products, and the architecture behind them.
These are working notes from building Nieuw Solutions: how we think about agents, how we ship a product, and which technical choices we repeat on purpose.
The Agentic Shift: Why Every Business Needs an AI Agent Strategy Now
Autonomous agents are no longer a research demo. They plan a task, use tools, and carry the work forward without a person clicking through every step. The companies that benefit are the ones that decide, early, which decisions an agent may make and which ones still need a person.
An agent strategy starts with a boundary, not a model. Pick one workflow with a clear input, a clear output, and a cost when it is wrong. Give the agent the tools for that workflow and a way to stop. Measure whether the work got done, not whether the demo looked impressive. Then widen the boundary.
We run this way inside our own products. Agents handle repetitive judgment — sorting, drafting, checking, routing — and people keep the decisions that change a customer, a price, or a commitment. That split is the strategy. The model can change. The boundary should be deliberate.
From Zero to SaaS: How We Build and Launch AI Products in 90 Days
We do not start with a platform. We start with a user who has the problem this week, a sentence that describes the outcome they will pay for, and the smallest product that delivers it.
The first month is for proving that sentence. We talk to the people who feel the pain, throw away the version of the idea they do not recognize, and build only the path from their input to the result they asked for. If we cannot describe that path on one page, we are not ready to write the rest of the software.
The second month is for making that path reliable enough that a stranger can use it without us in the room. The third is for charging, supporting, and watching where it breaks. Ninety days is a constraint we use so the product meets a customer before the architecture becomes the project. Individual products still take the time they take. The point is to reach a real user before we scale the system around a guess.
AI-Native Architecture: Lessons from Six Ventures and Fifty Deployments
After six products and more than fifty agents in production, the choices that keep paying off are boring.
Keep the model behind an interface you can replace. Log the input, the output, and the decision the system made, so a bad run can be explained later. Put rate limits and a human stop on anything that spends money or emails a customer. Prefer a narrow agent that does one job over a general agent that has every credential we own.
Shared infrastructure helps — the same ways of deploying, observing, and rolling back — but each product keeps its own data and its own failure domain. A studio is not one application with six skins. It is several products that can die or succeed without taking the others with them.
If you want to talk about applying any of this to your own product, write to martin@nieuw-solutions.com.
The Agentic Shift: Why Every Business Needs an AI Agent Strategy Now
Autonomous agents are no longer a research demo. They plan a task, use tools, and carry the work forward without a person clicking through every step. The companies that benefit are the ones that decide, early, which decisions an agent may make and which ones still need a person.
An agent strategy starts with a boundary, not a model. Pick one workflow with a clear input, a clear output, and a cost when it is wrong. Give the agent the tools for that workflow and a way to stop. Measure whether the work got done, not whether the demo looked impressive. Then widen the boundary.
We run this way inside our own products. Agents handle repetitive judgment — sorting, drafting, checking, routing — and people keep the decisions that change a customer, a price, or a commitment. That split is the strategy. The model can change. The boundary should be deliberate.
From Zero to SaaS: How We Build and Launch AI Products in 90 Days
We do not start with a platform. We start with a user who has the problem this week, a sentence that describes the outcome they will pay for, and the smallest product that delivers it.
The first month is for proving that sentence. We talk to the people who feel the pain, throw away the version of the idea they do not recognize, and build only the path from their input to the result they asked for. If we cannot describe that path on one page, we are not ready to write the rest of the software.
The second month is for making that path reliable enough that a stranger can use it without us in the room. The third is for charging, supporting, and watching where it breaks. Ninety days is a constraint we use so the product meets a customer before the architecture becomes the project. Individual products still take the time they take. The point is to reach a real user before we scale the system around a guess.
AI-Native Architecture: Lessons from Six Ventures and Fifty Deployments
After six products and more than fifty agents in production, the choices that keep paying off are boring.
Keep the model behind an interface you can replace. Log the input, the output, and the decision the system made, so a bad run can be explained later. Put rate limits and a human stop on anything that spends money or emails a customer. Prefer a narrow agent that does one job over a general agent that has every credential we own.
Shared infrastructure helps — the same ways of deploying, observing, and rolling back — but each product keeps its own data and its own failure domain. A studio is not one application with six skins. It is several products that can die or succeed without taking the others with them.
If you want to talk about applying any of this to your own product, write to martin@nieuw-solutions.com.