Illustrative engagement
Your first release, built to survive the second.
An illustrative engagement for a founder, product team or company launching a new software product without enough internal engineering capacity.
Illustrative: how we would scope this, not a completed client project.
The situation
Where it breaks today.
Common patterns we plan for, not a description of a specific client.
An MVP with no structure
A fast first version hard-codes decisions that the second release has to undo.
Accounts that don’t separate
Tenants, roles and billing are added late, so data isolation becomes a retrofit.
Releases nobody can roll back
Deployments are manual, so every release is a risk and a rollback is guesswork.
What we’d build first · illustrative
Architecture first, then the smallest release worth shipping.
A possible first scope. The real one is agreed with your team after discovery.
Product architecture
Data model, tenancy, roles and integration boundaries decided before the first screen.
The core journey
One user journey working end to end on the web, with mobile where the product needs it.
An admin portal
The tools your team needs to support customers from the first release.
Deployment you can reverse
A repeatable release path with monitoring and a rollback route.
Decisions we’d make early
Structure the first release for the second.
The expensive-to-change decisions come first, so later changes stay cheap.
Design tenancy on day one
Separate each customer’s data and permissions in the model, not in the screens.
Trade-offA slower first sprint, but no retrofit when the second customer arrives.
Ship one journey, not every feature
The first release proves the core journey end to end.
Trade-offA shorter feature list at launch, but real feedback sooner.
Automate releases early
A pipeline and rollback route exist before the first customer does.
Trade-offSet-up effort before launch, but every later release is cheaper and safer.
How we’d judge it
A product built quickly, but with enough structure to evolve beyond the first release.
Success is defined with your team before development begins.
End-to-end journey
The core user journey works from end to end.
Tenant isolation
Accounts and permissions remain isolated.
Safe rollback
A release can be monitored and rolled back.
What stays with you
Your product, your IP.
The product, its source code and its IP are yours under the engagement agreement. Hosting on Vloud is optional; we can deploy to your own cloud account instead.
- Service
Web Application Development
Web platforms and portals designed around real users, business workflows, and long-term maintainability.
Explore - Service
Mobile Application Development
iOS and Android applications for teams that work away from a desk, sharing one architecture with the web.
Explore - Cloud deployment, hosting, and operations
Vloud
Cloud deployment, hosting and operations platform, offered as SaaS. It runs our own products and hosts client systems.
Explore
Who owns the code?
You do, for the custom work we build for you. It is set out in the engagement agreement. Our own products stay ours.
Is our data ours?
Yes: your data belongs to you.
Will you sign an NDA?
If you need one, yes.
How do we start?
With a free 30-minute discovery call about the workflow, then a short discovery that turns it into an architecture and a phased plan.
How long will it take?
It depends on scope. We confirm scope, timeline and price in a written proposal after discovery.
Where is it hosted?
We can host in-region when data residency matters, or deploy to your own cloud account instead.
Start a conversation
Working through a similar challenge?.
Free 30-minute discovery call. Bring the workflow; we’ll tell you whether it’s a product fit, a custom build or neither, and what a first release could include.