For founders
AI SaaS development for founders
We build our own SaaS. Nure AI OS, Desi and Logi are products we ship, price, support and keep running. When we build one with you, you get a team that has already had to make it pay.
The failure mode is the gross margin
An AI SaaS that works and an AI SaaS that survives are different products. The first one needs the feature to be good. The second needs the cost of serving a customer to stay below what that customer pays, every month, as usage grows.
This is where most AI products quietly go wrong. Token cost per action is set by architecture decisions taken in the first fortnight, usually by someone optimising for a demo. By the time it shows up in the numbers it is a rewrite, not a tuning exercise.
The founders who get this right decide early which work the model does and which work code does, and they measure cost per unit of value from the first week rather than the first invoice.
What we build with founders
The product, end to end
Multi-tenant application, billing, onboarding, admin, the unglamorous surfaces a SaaS needs to be sellable rather than demonstrable.
An architecture with known unit economics
Cost per action, modelled before it is built and instrumented once it is. You should be able to answer what a customer costs you at a hundred users and at ten thousand.
Intelligence placed deliberately
Deterministic core, retrieval over the product's own data, small tuned models for the repeating decisions, a general model for the open-ended. Each one where it earns its cost.
The data asset
A SaaS that runs an operation accumulates something nobody else has. Designing for that from the start is the difference between a product and a wrapper.
Compliance that is built in
Transparency, record keeping and data handling engineered into the system rather than written into a policy. If you sell in the EU this stops being optional.
A handover you can hire against
Standard foundations, documented architecture, no dependency on us. Your first engineering hire should be able to read it and keep going.
Why build with us
We are not consultants who have read about this. Nure AI OS is our flagship and we operate it. We have made the pricing mistakes, the architecture mistakes and the scope mistakes on our own products, with our own money.
That shows up as uncomfortable questions early. What does a customer cost to serve. Which of these features is the product and which is a demo. What happens to your margin when usage triples. Those questions are cheaper now than in your seed round.
And we publish our engineering. The research on this site is open and cited, including the parts where we say we could be wrong. You can read how we think before you decide whether you want us thinking about your product.
How we work with founders
- 01
Pressure-test the shape
What the product is, who pays, and what the smallest version is that someone would pay for. Most ideas get smaller here, which is the point.
- 02
Model the economics
Cost per action, cost per customer, and which architecture decisions move them. This is a spreadsheet before it is code.
- 03
Build the core product
The deterministic system first, intelligence placed where it earns its keep, instrumented so the numbers from step two can be checked against reality.
- 04
Launch and watch the meter
Real usage changes every assumption. The first month of production data is worth more than the three months of planning before it.
- 05
Hand it over properly
Documented, portable, and legible to the team you hire next. We are not interested in being load-bearing in your company forever.
Questions
- Do you take equity instead of fees?
- We are a product company, not an investor, and our default is a straightforward build engagement. If there is a genuine strategic fit we will talk about it, but we would rather be clear up front that building your product and owning part of it are two different relationships and we do not pretend they are the same one.
- What is the difference between AI SaaS and normal SaaS development?
- Two things, and neither is the model. First, your cost of goods sold is variable and usage-driven in a way traditional SaaS is not, so pricing and architecture are the same decision. Second, the product's value compounds with the data it accumulates, which means the data model deserves more attention than the feature list.
- How do we know what our AI product will cost to run?
- You model it: tokens per action, actions per customer, customers per tier. The arithmetic is not hard, it is just usually not done. We publish a worked example of that kind of audit on real published pricing, and we do the same exercise for a product before it is built rather than after the first bill.
- Can you build an MVP?
- Yes, and the useful definition of one is the smallest system that could be charged for, not the smallest system that could be demonstrated. Those are very different builds, and the first one is usually cheaper because it refuses more features.
- Who owns the intellectual property?
- You do. We build on standard, portable foundations and document the architecture so another team can take it on. A product you cannot move is a product someone else partly controls.
- Will you keep working on it after launch?
- If it is useful to you. But the handover is designed so that you do not need us, because a founder dependent on an outside team for their core product has a structural problem no contract fixes.
- What if we have not raised yet?
- Then the scope conversation matters more, not less. We would rather help you work out the smallest buildable thing that proves the product than take a brief that burns a pre-seed on features nobody has paid for yet.
The engineering, published
- What the frontier costs nowEvery current model priced against the same two workloads, and why the table lies.
- What tokens actually costThe self-hosting maths, and why the cheap-model story stopped being true.
- Small language models: the agent economicsWhy most of what a system does does not need most of a model.
- Gemini 4 Argon: the output limit is the storyWhy per-call budgets stopped bounding anything, and what to budget instead.
- AI implementation is an architecture decisionThe decisions that set your cost for the life of the product.
What we build against
- Anthropic's published API pricingPublished per-token rates. Unit economics start from a real price list, not an estimate.
- Regulation (EU) 2024/1689, the AI ActIf you sell into the EU, transparency and record keeping are product requirements from day one.
- OWASP Top 10 for LLM ApplicationsThe failure modes to design against before a product is in front of customers.
Bring us the idea, and the numbers you are unsure about
The first conversation is about what the product is and what it would cost to serve. If the economics do not work we would rather say so now.