AI products for startups
A working AI product in weeks, on your own accounts, with a written report every week.
Blog / Category
Custom software
Applications built for how a business actually runs: ordering, scheduling, billing, administration.
Off-the-shelf software fits the average business. When your operation is not average, the workarounds start: spreadsheets beside the system, copy and paste between tools, steps that live in someone’s head.
We build software around how your business actually runs, from the first prototype to a product in production, with the tests, security reviews and weekly reports that let you trust what ships.
This is for you if
- Your team works around your tools instead of with them
- You have a prototype or a proven method and need a real product
- You need to move fast without losing control of quality
Articles
A new site engine in one day, with every page proven identical
We moved evdevs.com from hand-uploaded static files to Astro on Vercel in one day. A parity check proved all 111 URLs matched, email never moved, and the site gained a lead pipeline.
Give the answer first: lead magnets that earn the contact
Our free self-checks give a scored result, the gaps and their fixes on the page, with no email required. Then they offer two ways forward and a report built to be forwarded. Here is how they work.
Production: what a prototype skips and a real system can’t
A prototype assumes every system answers and every input is clean. Production plans for the day they don’t. What we build into every system so it keeps working, and keeps someone responsible for it.
From zero automated checks to 918 in under nine weeks
Sixteen weeks of a product had no automated checks. By its September release it had 918, and a gate that blocks any release when one fails. What we built, and the two times the safety net itself needed fixing.
Trust: a successful request is not a correct answer
An AI call that returns successfully can still be wrong. The checks we build around every model before people act on its output: structured outputs, rules alongside the model, fallbacks, provenance, review and tests.
One system, many customers: proving their data stays apart
A product that holds several companies’ sales calls must never let one see another’s. Saying so is easy. Here is how we checked it on the live system, and what we built so the answer stays true after every change.
Prompts are code: version them, test them, review them
A prompt decides what your AI system does, so change it the way you change code: in version control, reviewed, tested against fixed examples, and recorded on every output so you can explain it and roll it back.
Building a school platform with an AI pair programmer
97 code changes, 74 of them written together with an AI coding assistant. How we built SuperEscuela’s student app and teacher records system, and the rules that kept the AI useful and the data safe.
How to test a RAG system before your team trusts it
A RAG demo answers the questions its builders thought to ask. How to test retrieval and answers separately, check citations automatically and agree a pass mark in advance, so your team can rely on what it says.
Integrating APIs that fail: retries, idempotency and backoff
Every external API will time out, throttle you or change without notice. The patterns that keep an integration correct when that happens: backoff with jitter, idempotency keys, retry budgets, dead-letter queues and reconciliation.
Build on your own accounts from day one
Who holds the repository, the cloud account and the AI keys decides how easy it is to change partners, hire a team or raise the next round. Why we build on the client’s own accounts from the first day.
Let customers connect their own CRM in one click
Self-serve software cannot ask every customer to copy an access key and book a call with their admin. How we built a one-click, read-only CRM connection, and why “what you did not share” deserves a screen of its own.
Test the paths that have never run
A billing error would have given top-tier customers a fifth of what they paid for. It was waiting in a feature nobody could test yet. How one round of hands-on review found it, and 30 other problems, before the first invoice.
Governability: who changed the prompt, and can you roll it back?
An AI feature is governable when you can say which prompt, model and settings produced any output, who approved that version, and how to go back to the previous one. How to build that in from the first release.
Built for the oldest phone: offline-first, no passwords, no frameworks
SuperEscuela is a free school for Spanish-speaking children who may have an old phone and a weak signal. The technical choices that follow from that, and why “light” is a feature, not a compromise.
Limit the blast radius: decide what a failure is allowed to break
Every integration and every AI feature will fail at some point. Deciding in advance how far that failure can spread is what keeps one bad source, one bad deploy or one bad model output from taking the rest of the business with it.
Senior team or first hires? The first 90 days after a round
After a raise, the instinct is to hire. Hiring is right, but it is slow, and the first months decide what the next round sees. When a senior team that ships from week one makes more sense, and how it should hand over.
The AI harness: the code around the model is what makes it reliable
A model call is easy to add and hard to depend on. The harness around it, from prompt templates and schema validation to fallbacks and provenance, is what turns a model into a feature people can act on.
Agent or workflow? When to let the model decide
Most AI features are more reliable, cheaper and easier to test as a fixed workflow with AI in a few steps. How to tell when an autonomous agent is worth its cost, with a checklist you can use on your next feature.
Data contracts: agree on the shape before you connect two systems
Integrations break quietly when two systems disagree about what a record looks like. A data contract makes that agreement explicit, testable and owned, so bad data stops at the boundary instead of reaching your reports and your AI.
What the first eight weeks of an AI product look like
A sales-coaching expert had a method proven by hand, a clickable mockup and an 8-week plan. The core product was working in eight weeks, as planned. Week by week, what that took, and how risks were handled along the way.
Related work
An AI sales-coaching product: from clickable mockup to working product in 8 weeks
Sales technology · client details withheld
A sales-coaching expert had a method proven by hand and a clickable mockup. We built the product around six AI agents that score calls against the client’s own scorecard, watch the CRM pipeline, prepare managers, coach reps, run one-to-ones and diagnose dips, with self-serve sign-up, CRM connection and billing.
Sales technology
A mutual fund management tool with an AI assistant
Financial services · client details withheld
A management tool for mutual funds, built together with an AI assistant for the team that runs them.
Financial services
SuperEscuela: a free school, built and written with AI
Non-profit education platform · our own project
A school that is played: free, ad-free and offline-first, for Spanish-speaking children, with a records system for teachers. Built with an AI pair programmer; its content is written by an AI pipeline against Costa Rica’s national curriculum: 733 topics, 2,786 lessons and 13,705 practice questions so far.
Education
Have a method
worth turning into a product?
Tell us where your operation feels slow, repetitive or difficult. We will tell you what is worth building, and what the next practical step could be.
Prefer to write directly? enable JavaScript to see the address