Custom software development: web apps, portals, MVPs, internal tools and native mobile
We build production software end to end: customer portals, internal tools, SaaS MVPs, data-heavy web apps and native mobile. Engagements run $35,000 to $150,000 depending on surface area and integration depth. You own the repository, the infrastructure accounts and the migrations from the first commit.
What you get
A repository you own from commit one — Your GitHub organisation, your Vercel or cloud account, your database. Not a staging environment we hold and hand over at the end, and not a proprietary builder you can never leave.
A migration-first database — Every schema change is a reviewed, versioned migration, not a click in a dashboard. One client engine we operate carries 456 SQL migrations across 239 production tables, which is only survivable because every one of them is in the repository.
Row-level security audited as a deliverable — Access rules live in the database rather than only in application code, and they are reviewed as part of the migration process. An authorisation bug in application code is a bug; an authorisation bug in the database is a breach.
CI that blocks bad deploys — Tests, type checks and assertions that run on every pull request. One engine we run has 157 CI test guards across 25 GitHub Actions workflows. The point is not the count — it is that a regression fails in CI instead of on a customer.
Native mobile when the product needs it — SwiftUI applications with live StoreKit 2 subscriptions running against real purchase flows. Four native mobile apps in the portfolio, so subscription plumbing is a known quantity rather than a research project.
Real third-party OAuth, not a mock — One Tauri desktop application we built publishes to five social platforms through genuine OAuth flows, with a hash-chained audit log recording every publish. Integrations get built against the real API and the real failure modes.
An audit trail where it matters — Where the software takes actions on a user's behalf, those actions are logged in a form that cannot be quietly edited afterwards. Hash chaining is cheap to add at the start and impossible to reconstruct later.
Environments and a deploy path — Local, preview and production, with previews on every pull request so stakeholders review working software rather than screenshots in a deck.
Documentation written for the next engineer — Architecture notes, runbooks and a decision log explaining why the awkward parts are the way they are. Assume the next person to open the repository is not us.
A handover that actually completes — Credentials, accounts, domains, runbook and a working session with whoever inherits it. Ownership transfer is a scheduled task with a date, not a promise.
Published pricing
Internal tool or portal — $35,000–$60,000 then Optional support retainer. One clear workflow, one user type, integrated with the systems you already run. Auth, roles, audit trail, deploy pipeline. Timeline: 8–14 weeks.
SaaS MVP — $60,000–$100,000 then Optional support retainer. Multi-tenant application with billing, onboarding, roles and the two or three workflows that prove the product. Timeline: 12–20 weeks.
Production web application — $100,000–$150,000 then Optional support retainer. Data-heavy application with multiple user types, deep integrations, background processing and reporting. Timeline: 20–30 weeks.
Native mobile add-on — Quoted with the platform then App store maintenance. SwiftUI or equivalent, with StoreKit 2 subscriptions where the product sells through the store. Timeline: Runs alongside the platform build.
Discovery phase — Scoped separately, credited to the build. For programmes where the shape is genuinely unknown. Produces working software, not just a document. Timeline: 2–3 weeks.
How the work actually runs
01. Shape (Weeks 1–2) — We work out what the software has to do, who uses it, what it integrates with and what the first shippable slice is. Not a requirements document — a written scope with a data model, the user types, the integration list and an explicit list of what is out of scope. Output: A scope document, a data model, a phase plan with prices, and a named smallest useful thing to ship first.
02. Foundation (Weeks 2–5) — Repository, environments, database with migrations, authentication, roles and row-level security, CI with tests that block merges, and the deploy pipeline. Boring, and the reason the middle of the project is not chaos. Output: A deployed, empty-but-real application in your accounts, with CI green and preview deploys on every pull request.
03. Build in slices (Weeks 5–20+) — One workflow at a time, each one shipped to preview and reviewed by someone who will actually use it. Integrations built against real APIs in sandbox. Every schema change is a migration; every risky path gets a test. Output: Working software growing every week, with a demo you can click rather than a status percentage.
04. Harden (Final 2–4 weeks) — Load and edge-case testing, authorisation review against the row-level security rules, error handling and observability, backup and restore rehearsed rather than assumed, and the accessibility pass. Output: A hardening report: what was found, what was fixed, what was accepted and why.
05. Launch and hand over (Final week, then ongoing) — Production launch, monitoring and alerting live, runbook written, and a working session with whoever owns it next. Then either a support retainer or a clean exit — both are fine. Output: Live software, a runbook, transferred credentials, and a decision log explaining the awkward parts.
Who this is for
Businesses whose operations have outgrown spreadsheets, shared inboxes and a stack of SaaS subscriptions that do not talk to each other.
Founders with a validated problem who need a real MVP rather than a prototype that has to be thrown away.
Teams who need a portal, dashboard or internal tool that touches production data and therefore has to be built properly.
Who this is not for
Projects with no decision-maker available weekly. Custom software dies from unanswered questions faster than from hard problems.
Ideas that a configured off-the-shelf tool would solve. We will say so, and we would rather lose the build than sell you one you did not need.
Fixed-price megaprojects with a frozen twelve-month specification. Nobody delivers those well, including us.
The receipts behind those claims
487,000 lines in one client engine — Approximately 487,000 lines and 2,245 commits since 13 June 2026 in a single client codebase this team builds and operates. Scale that is maintained daily, not a line count from an archive.
456 / 239 SQL migrations across production tables — 456 reviewed migrations against 239 production tables in that same engine. Every schema change versioned in the repository, which is the only way a database that size stays changeable.
157 CI test guards across 25 workflows — 157 continuous-integration guards running in 25 GitHub Actions workflows, so regressions are caught by a pipeline rather than by a customer.
471 C# scripts in a Unity 6 game — A shipped Unity 6 title with 465 C# scripts, plus four native mobile applications. The team's range is not limited to web forms over a database.
Production web application — market: $150,000–$500,000; here: $100,000–$150,000
Ownership of code and infrastructure — market: Frequently the vendor's; here: Yours from the first commit
What does custom software actually cost?
Industry ranges are wide because the word covers everything from a form over a database to a trading platform. As a benchmark, a SaaS MVP is commonly quoted at $50,000 to $120,000 and a production web application at $150,000 to $500,000. Our engagements run $35,000 to $150,000, which puts us at the lower end of the MVP band and well under the production-application band. The reason is not that we work cheaply. It is that we refuse to build the parts you do not need yet, and we start every engagement with the smallest slice that produces working software. Most of the money wasted in custom software is spent on features specified in month one and deleted in month nine. The honest variable is integration depth. A portal that reads from one API is a different animal to one that reconciles three systems with conflicting identifiers and no shared source of truth. We price after the shaping phase for exactly that reason, and we will tell you which category you are in during the first call.
Should you build custom software or buy an off-the-shelf tool?
Buy when the workflow is standard and the tool is close. Accounting, payroll, email, CRM and helpdesk are solved problems, and building your own is a hobby with a business attached. Build when the workflow is the thing that makes you money, when three tools each solve a third of the problem and nobody solves the joins, or when the manual reconciliation between systems is now a job somebody does full time. The test we apply is simple: describe the process to us, and if the answer includes a person copying data from one screen into another, there is a build worth costing. If the answer is that an existing tool does it but nobody configured it properly, the correct engagement is configuration, not development, and we will say so.
Who owns the code, the data and the infrastructure?
You do, from the first commit. The repository lives in your organisation, the hosting and database accounts are yours and billed to you, and the domain is registered to you. We work inside your accounts rather than handing over a copy at the end, because a handover that has not been rehearsed is not a handover. This is a deliberate commercial position. Vendors who hold the accounts have leverage; vendors who do not have to be worth keeping. It also means the awkward conversation about leaving is a scheduling problem rather than a negotiation.
Custom software projects always run over.
Many do, and usually for one of two reasons: a twelve-month specification frozen before anyone has used anything, or a decision-maker who is unavailable for weeks at a time. We attack both directly — phases are priced individually, the first shippable slice lands early, and we require a weekly decision-maker. If those conditions are not available on your side, the project will run over regardless of who builds it, and we would rather say so before the invoice.
An offshore team quoted a third of the price.
They may well deliver. What you are buying at our price is the operating discipline — versioned migrations, row-level security reviewed as a deliverable, CI that blocks merges, and a handover into accounts you already own. If a cheaper quote includes those, take it. If the quote is cheaper because those are absent, the saving is a loan against year two, when nobody can safely change the schema.
How much does it cost to build a custom web application?
TrainYourAgent engagements run $35,000 to $150,000: roughly $35,000 to $60,000 for an internal tool or portal, $60,000 to $100,000 for a SaaS MVP, and $100,000 to $150,000 for a production web application. Industry benchmarks put SaaS MVPs at $50,000 to $120,000 and production web applications at $150,000 to $500,000.
How long does custom software take to build?
Eight to fourteen weeks for an internal tool or portal, twelve to twenty weeks for a SaaS MVP, and twenty to thirty weeks for a production web application. The first working slice ships within the first few weeks in every case, because a project that shows nothing until month four cannot be steered.
Do you build mobile apps as well as web apps?
Yes. Native mobile is built where the product genuinely needs the camera, background location, offline behaviour or in-app purchases. The portfolio includes four native mobile applications, including SwiftUI apps with live StoreKit 2 subscriptions running against real purchase and restore flows.
Who owns the code you write?
You do. The repository is created in your organisation, the hosting and database accounts are yours and billed to you, and the domain is registered to you. Everything is delivered into infrastructure you already control rather than copied over at the end of the engagement.