Deliverables
What you actually get
A deployed product, the code that runs it, and the accounts it runs in. Here is the full list, and the exclusions list underneath it.
Short answer
A deployed web application with three working features, a database, authentication and payments where needed, transactional email, analytics, and a search and AI visibility layer — plus the full source code transferred to your GitHub account, a recorded handover, and a 7-day bug fix window. All for a fixed $3,500 AUD.
A working web application
Three core features built end to end, not stubbed out or mocked. A stranger can arrive, use it and get the outcome you promised without you in the room.
Next.js, React and TypeScript
A mainstream, type-safe codebase. Chosen deliberately for how easy it is to hire for after handover — the most widely known web stack there is.
A database, set up properly
PostgreSQL or MongoDB depending on what the product needs, with constraints enforced at the database level rather than hoped for in the code.
Authentication
Email and password or Google sign-in, password reset, and sessions that survive a refresh. Only if your product needs accounts — a one-shot tool should not have a sign-up wall.
Stripe payments
Hosted Stripe Checkout with signature-verified webhooks, replay protection and idempotent order recording. This is the part that quietly loses money in badly built products.
AI integration
OpenAI or Anthropic APIs with streaming responses, server-side keys only, and per-user usage limits so one enthusiastic user cannot run up a four-figure bill.
Transactional email
Sign-up, reset, receipt and notification email sent from your own verified domain, so it lands in inboxes instead of spam folders.
Deployment on your own accounts
Live on Vercel with your custom domain and SSL, under your own hosting login. You are not dependent on us for access.
Search and AI visibility
Metadata, structured data, a generated sitemap, robots rules and an llms.txt file — so Google and AI assistants can both read the product from day one. Most rushed builds skip this entirely.
Analytics
Wired in before launch, with conversion events on the actions that matter, so you can tell whether anyone is actually using it.
Full source code and repository transfer
The GitHub repository transferred to your account with complete history. 100% ownership, no licence fees, no lock-in, no ongoing obligation to us.
A recorded 30-minute handover
How it works, how to change the content, where everything lives, and what to do first. Recorded, so you can watch it again in a month.
7-day bug fix window
Seven days after handover, anything broken gets fixed at no cost. Real users find things a build never will.
What is not included
- A bespoke design system with its own visual language — that is a separate project
- A fourth feature. Three is the scope; more is a second build.
- An admin back-office
- Team accounts, seats and role permissions
- Native iOS or Android apps in the app stores
- Custom AI or machine-learning model training
- Automated test suites
- Architecture for a hundred thousand users you do not have yet
- Migration of years of existing data (can be quoted separately)
- Ongoing development after the support window
Why the exclusions list is the important half
An inclusions list is easy to write and tells you very little, because everybody's is similar. The exclusions list is where the honesty is, and it is the document that prevents an argument three weeks in.
Every item on that list is there because it either cannot be done well in the time, or because it should not be done at all in a first version. An admin panel is the clearest example: it feels essential, and for your first few weeks the database is a perfectly good admin panel while you have more urgent problems.
If something on the exclusions list is genuinely essential to your product, say so on the discovery call. It may mean the honest answer is a longer build or a different provider, and that is a better thing to learn in the first thirty minutes than in the second week.