09
Custom software development is building the system your business runs on when no product fits: platforms, SaaS products, customer portals, internal tools and MVPs, with the APIs, data model and failure handling behind them.
Depends onWhen it fails
Example fallback plan, one answer per outside service
Part of your business runs on spreadsheets, email and a tool that almost fits. You need a system built around how you actually work.
Sound familiar?
You need a platform, product or API built to your standards: a written architecture, typed code, reviewed pull requests, tests against a real database, security checks in the pipeline and a release you can verify.
Sound familiar?
What you can hold the work to, in plain terms.
Bookings, orders, documents and payments in one data model, with roles that decide who sees and changes what, and an audit trail of who did.
Every outside dependency, from payments to email to an AI model, has a written failure mode before it is built: recover, fail over, degrade or refuse.
The same gates run on every change, and a release counts only when production reports the build that was tested.
The repository, infrastructure definitions, decision records and runbooks are handed over, so another team could run the system without us.
Three lanes: what people sign in to, the work that runs behind it, and every outside service it depends on, each with a written answer for the day it fails.
Serve lane: customers, staff and admins sign in to a portal, a workspace or a console. Requests pass an edge network with CDN, WAF and TLS to the application and its API, described by an OpenAPI contract, with roles, two-factor sign-in and an audit log, over a relational database, private document storage and a cache. Work lane: a transactional outbox written with each record feeds a queue and background workers; a scheduler sends reminders and follow-ups and runs retention clean-up; a reconciliation job checks payments against the provider. Depend lane: payments recover through reconciliation, email retries from the outbox, the AI model fails over to a second provider, and document sealing fails closed.
The disciplines inside this service, and the detail we work to in each.
01
The workflow walked through with the people who do it, then cut to a first release that can be priced and tested.
02
Decisions recorded with their reasons, and a data model designed before the screens that depend on it.
03
The screens people sign in to: customer and partner portals, staff workspaces and the back office behind them.
04
The back end that does the work: API contracts, background jobs, and the calls to payment, email and calendar providers.
05
A first release real users can complete end to end, built on the foundation the full product will keep.
06
The engineering that makes a system safe to change: every change gated and scanned, and every release traceable to the build that runs.
Most good platforms are mostly bought. We decide module by module and write down why, so custom code goes only where it pays for itself.
| Option | Fits when | What you own | Trade-off |
|---|---|---|---|
| Buy a product | Fits whenThe process is standard: accounting, payroll, e-signature. | What you ownYour data, within the vendor's export options. | Trade-offPer-seat fees, and the vendor's roadmap instead of yours. |
| Configure a platform | Fits whenA common process with your own fields and steps, such as a CRM. | What you ownA configuration inside their platform. | Trade-offLimits at the edges, and leaving is a project. |
| Extend with a custom module | Fits whenA product covers most needs, and one workflow sets you apart. | What you ownThe module and its API contract. | Trade-offTwo things to keep in step when the vendor changes. |
| Build a platform | Fits whenThe workflow, data or rules are the business, and no product fits. | What you ownEverything: code, data model and infrastructure definitions. | Trade-offYou fund its upkeep, so it needs an owner and a budget after launch. |
If a product fits, we will say so and help you choose it.
Every stage ends with a document you keep and a gate you can check.
The workflow walked through, the first release cut to what matters, and a price for it.
Exit gate: You sign off the phase-one scope and its acceptance tests.
You receiveWritten scope, prototype and a fixed price for phase one
Before any feature, a bare version of the whole system runs on staging: sign-in, data model, release pipeline and alerts.
Exit gate: A change travels from pull request to staging through every gate, and rolls back.
You receiveA walking skeleton on staging
Short increments on a system that already deploys, each one shown working on staging.
Exit gate: The phase-one acceptance tests pass on staging with realistic data.
You receiveWorking software on staging after every increment
Data migrated, a rehearsed release, then the first weeks watched closely by the team that built it.
Exit gate: Production reports the tested release, and every alert reaches a named person.
You receiveLive system, runbook and handover
Written down before work starts, so nothing is assumed.
The public frameworks we measure the work against, and the platforms we run it on.
Client cases name the industry and the stack, never the client.
Minute Notary is a notary office in Ottawa. We designed, built and run the platform behind it: booking and payment, secure documents, a workspace for notaries, and seals anyone can verify online.
A fixed, small first engagement, then the model that fits the rest.
A first engagement
A short, fixed-price piece of work before any build: the first release defined, prototyped and priced. The plan is yours even if you stop there.
Fixed price
Defined projects: a website, an assessment, a migration stage
One price for that scope
Time and materials
Ongoing improvement, support and discovery work
Billed for the time used
Dedicated team
Long programs such as a platform migration
A monthly rate per engineer
Custom software development is designing, building and running software around one organisation's own workflow, data and rules, instead of bending the business to a product. It covers business platforms, SaaS products, customer portals, internal tools, MVPs and the APIs behind them. It pays off when the workflow is what sets you apart and no product fits it.
It depends on scope, integrations and compliance, so we price in two steps. A fixed-price scope and architecture sprint produces a written scope, a clickable prototype and a fixed price for the first phase, with a range for the rest. You know what phase one costs before any build starts, and the plan is yours even if you stop there.
It depends on how many roles, integrations and compliance needs the first release carries, so the scope sprint ends with a date as well as a price. We cut scope before we stretch the date: the first release answers one question about demand or workflow, and everything else waits until users show what matters.
Buy when the process is standard, such as accounting, payroll or e-signature. Configure a platform when the process is common but has your own fields and steps. Build only the part that sets you apart, or when no product fits your data, rules or compliance needs. We decide module by module and record why, so most platforms mix bought and built parts.
A proof of concept shows that something can be built, often in code nobody ships. A prototype shows how it would work, usually as clickable screens. An MVP is working software that real users rely on, with the smallest scope that still tests the business idea. We build MVPs on the same foundation the full product will use.
Yes. Everything built for you is handed over: the repository, infrastructure definitions, decision records and runbooks, with admin access to every service the system depends on. Everything needed to build, deploy and run it is written down, so another team could take it over without depending on us.
Yes. Engineers are assigned to your roadmap at a monthly rate per engineer, work in your tools and routines, and stay with the product, so knowledge builds up instead of leaving with each project. It suits long programmes and growing products. For a defined first release a fixed price usually fits better, and many teams switch after launch.
Each outside dependency gets a written failure mode before it is built: recover, fail over, degrade or fail closed. On the notary platform we run, payment events are reconciled with the provider on a schedule, emails leave through an outbox, the assistant fails over to a second model provider, and no seal is issued without a trusted timestamp.
Yes, starting with a fixed-scope codebase review. We reproduce the build and deploy, run the tests and security scans, read the data model and list what blocks production: missing authorisation rules, error handling, tests or a release path. You get a ranked fix list and a straight answer on repair versus rebuild.
Requirements come from OWASP ASVS 5.0 and the OWASP API Security Top 10, and the pipeline checks every change with secret scanning, static analysis and dependency and container scans. Staff sign in with two factors, roles limit what each person can see and do, and documents sit in private storage. Independent penetration tests are scoped separately.
Yes. Our office is in Ottawa, and we designed, built and run the platform of an Ottawa notary office, Minute Notary. Most projects are for clients in other cities and countries, so we work remotely by default and meet in person when that helps the project.
We can. The team that built it runs it under Hosting & maintenance: monitoring, patching, backups with restore tests and an alert for each outside dependency, with new features under time and materials or a dedicated team. If your own team takes over, the handover includes runbooks, access and a walkthrough of every alert.
Plain-language articles on custom software development, with their sources.
Custom software17 min read
AI is changing software engineering, not replacing it: what controlled trials, DORA, Stack Overflow and BLS data show, and which skills now matter.
Updated
Custom software19 min read
How augmented reality programming works: tracking, anchors and rendering, the main SDKs (ARKit, ARCore, Unity, OpenXR, WebXR) and how AR apps are built.
Updated
Custom software17 min read
How software gets built: the SDLC phases, waterfall, agile and DevOps, built-in security, build versus buy, cost drivers and how to judge a development partner.
Updated
Custom software19 min read
Where test automation stands in 2026: shift-left CI, Playwright, Cypress and Selenium, contract, visual, accessibility and AI testing, and what to adopt now.
Updated
Web development16 min read
AR adds digital content to your view of the real world; VR replaces that view. How each is used for training and remote work in 2026, and which one fits.
Updated
The same engineers answer for each of these.
Tell us what you run and what is getting in the way. You get a reply within 24 hours.
