You describe it in plain English
Say what the thing does, who uses it, and what has to be true for it to be useful. Speak, write, send a voice note, or paste an email thread. There is no template to fill in and no vocabulary to learn.
What we build
A sentence goes in. Working software comes out.
Applications, AI agents and the connections between them — described in plain English, delivered running on the internet with real logins and real data.
No technical brief. No specification to write. You describe it the way you would describe it to a person.
Most software projects fail in translation. You know what the business needs; a specification turns it into a document, the document turns into tickets, and the tickets turn into something nobody asked for. We remove the translation layer. You describe what you want in your own words, we build it, and you look at a working version early enough that being wrong is cheap.
How the description becomes a build
The intake is a conversation, not a form. It is the only part of the process that needs your time.
We ask the questions you did not think of
Who is allowed to see this? What happens when two people edit the same record? What should it do when the payment fails? These are the questions that decide whether software works in practice, and we ask them up front rather than discovering them in production.
You get the description back, written down
Before anything is built, we send you what we heard: the screens, the rules, the users, the edge cases. In your language, not ours. Correcting a paragraph is cheaper than correcting a codebase.
Scope is a conversation, not a change order
When you want something different halfway through — and you will — you say so. There is no change-request process, no re-scoping meeting, and no invoice attached to changing your mind.
What actually gets delivered
Not a prototype, not a clickable mockup. A real application, on the internet, that a customer can use.
A web application on a real domain
Responsive, works on a phone, on your own domain with a certificate. Not a preview link that expires, and not something that only runs on a laptop.
Real accounts and real permissions
Sign-up, sign-in, password reset, email verification, roles and permissions. Single sign-on through Google or Microsoft where you need it, so your team does not manage another password.
A real database with your real data
Persistent, backed up, and yours. You can import what you already have in a spreadsheet, and you can export all of it whenever you want.
AI agents that do the work, not demos of it
An agent that reads incoming email and files it, screens applicants, drafts a reply, watches a queue, or answers questions about your own documents. Given real access, real logins and real limits on what it is allowed to do.
Connections to the tools you already pay for
Payments, email, calendars, e-signature, accounting, CRM, storage — thirteen categories of integration, off until you need them. If a service has an API the application can use it; if it does not, we say so before you plan around it.
The unglamorous parts, done
Transactional email that lands in the inbox rather than the spam folder, file uploads, PDF generation, search, audit history, admin screens. The work that never appears in a pitch and always appears in a support ticket.
How it changes after it ships
Shipping is the start of the relationship, not the end of the engagement.
You see it early and often
You get a link to the real thing while it is still being built. Feedback lands against something you can click, which is the only kind of feedback worth having.
A staging copy to try things on
A second, identical copy of your application with throwaway data. Try the risky change there, break it freely, and promote it when you are happy.
Changes ship without an outage
Updates go out while people are using it. If a release misbehaves, it is rolled back to the previous version rather than fixed live under pressure.
One person who knows your application
Not a ticket queue. Someone who remembers why the third screen works the way it does, because they built it.
The specifics
What comes with every application
The list below is inherited, not quoted for. You do not ask for it and you are not billed extra for it.
| Item | What you get |
|---|---|
| Delivery | A live web application on your own domain, with TLS |
| Accounts | Email + password, magic link, Google and Microsoft SSO |
| Permissions | Roles, per-record access rules, admin view |
| Data | Managed relational database, daily backups, full export on request |
| Environments | Production and staging, with separate data |
| Transactional sending on an authenticated domain (SPF, DKIM, DMARC) | |
| Files | Upload, storage and delivery, access-controlled |
| Monitoring | Uptime checks, error alerting, performance traces |
| Audit | A record of who changed what, and when |
| Agents | Scheduled and event-driven, with scoped credentials and spend limits |
Questions people ask
What if I do not know exactly what I want yet?
That is the normal case, and it is the reason the intake is a conversation. Most people know the problem precisely and the solution vaguely. Describing the problem is enough to start.
How different is this from asking an AI tool to build me an app?
A cheap AI tool gives you something that looks like an application. It usually has no real accounts, no permissions worth the name, no backups, no monitoring, and nobody responsible when it stops. What we deliver is the same thing a competent engineering team would hand you, and the difference shows up the first day a real customer uses it.
Can you work from something I have already started?
Often, yes. Send us what exists — a prototype, a spreadsheet that has grown teeth, a half-finished build from a previous developer — and we will tell you honestly whether it is worth continuing or worth replacing.
Do I get the source code?
Code ownership and deployment into your own cloud are on the roadmap rather than available today. If that is a condition of working together, say so early — it changes which stage of the roadmap matters to you.
What will you not build?
Anything we cannot run responsibly: a product whose regulatory burden we are not equipped to carry, or something whose entire value is a third-party service that forbids it. We would rather say no in the first conversation than halfway through.