SaaS products, customer portals and internal platforms — built for real load, real permissions and the audit question nobody asks until year two.
Naming which one you have changes the architecture, the timeline and who needs to be in the room.
Multi-tenant SaaS with subscriptions, onboarding and per-customer isolation. The hard parts are billing edge cases and tenant data separation, not screens.
Customers, suppliers or field staff seeing live records from your ERP — with permissions that mean nobody sees a row they shouldn't.
A monolith that still works but nobody dares change. Modernised in slices, with the old system running until each slice is proven.
Source, infrastructure and documentation sit in your accounts from the first commit.
A product other companies log into, with the commercial machinery that goes around it.
A window onto live records, so status answers itself instead of arriving by email.
The operational tools your team lives in all day, built for speed of use rather than first impressions.
Moving off a system you cannot safely change, in slices, without a big-bang weekend.
None of these are visible in a demo, and all of them are cheaper to build in than to retrofit.
Load-tested against production-sized volumes, not the 200 rows a demo uses. Slow queries get found before your users do.
Access rules enforced at the API, not hidden in the UI — so a rebuilt screen or a new integration cannot leak a record.
Who changed what and when, immutable and queryable. The question arrives eventually, usually from a customer or an auditor.
A backup nobody has restored is a hope. We run the restore during the build and write down how long it took.
Logs, traces and alerts wired up while it is calm, so the first production problem is diagnosed rather than guessed at.
Automated pipeline, staging that matches production, and a rollback path — so shipping on a Thursday is uneventful.
Not coverage theatre — automated tests on pricing, permissions and the calculations you would be embarrassed to get wrong.
Architecture notes, runbooks and decisions written down, because handover to your own developers is a planned outcome.
Widely-staffed tools, chosen so another team could pick your system up. No in-house framework you would be locked into.
Answered the way we'd answer them on the call.
Ask us something elseYes, and it usually works better. Your team knows the domain; we bring delivery capacity and architecture. We work in your repo, your review process and your board.
Almost never. Most legacy pain is two or three slow paths and an absent API layer. We look for the smallest change that removes the pain before proposing a rebuild.
Your cloud accounts, your bill, no markup. We size the infrastructure against your real volumes during architecture so the monthly number is known before launch.
That is usually the point. We build against Odoo and other ERPs through a proper API layer, so the portal reads live records rather than a nightly copy that drifts.
A support retainer with a written response time, or a clean handover to your team with runbooks and architecture notes. Both are normal; neither is a hostage situation.
Sprint by sprint. Priorities can move freely inside an agreed budget; anything that changes the total gets quoted before it is built, not discovered in an invoice.