Approach
How we plan, architect and run software that stays affordable.
01How it starts
Four steps before anything big is signed.
- 01
A conversation
Thirty to forty-five minutes on what you’re building, what’s in the way and what has to be true. If you’d rather sign an NDA first, we do that before any details change hands.
- 02
A written reply
What we heard, what we’d want to find out, and whether we’re the right team. Sometimes the honest answer is that you need someone else, and we’ll say so.
- 03
A fixed-scope first step
A discovery sprint, a codebase assessment or an AI feasibility sprint: a short piece of work with a clear deliverable, so you can judge us on output rather than promises.
- 04
A proposal you can read
Team shape, increments, risks, what you’ll receive at each stage and a cost range, with the assumptions written down so you can challenge them.
02Plan
Estimates that are honest about what isn’t known yet.
Every software estimate starts wide and narrows as decisions are made. Pretending otherwise is how budgets break. We commit to what can be known at each point, and tell you what would move the number.
02 · Product defined
0.5×–2×
An honest range 4× wide
- What we commit to here
- End of the first step
Discovery has set the scope, the users and what success means, and tested the riskiest assumptions. A budget range is now worth planning around.
03Architect
Start simple. Earn every part.
A system that works grows out of a simpler system that worked. So we launch with the fewest moving parts that do the job well, and add each new one when a measurement asks for it.
“A complex system that works is invariably found to have evolved from a simple system that worked.”
Container view · one system, three stages
01 · Launch
One deployable, clear modules, one database.
Fast to change, cheap to run and easy to reason about. Boundaries between modules live in the code, so a module can become a service later without a rewrite.
Modular application
One codebase, one deploy, boundaries enforced in code.
PostgreSQL
Data, background jobs and full-text search in one place to start.
Edge and CDN
TLS, caching and protection in front of everything, from day one.
Decisions, written down.
Anything you’d otherwise have to ask about in a year becomes a short decision record: what we chose, why, what it costs, and what would make us change our minds.
- Container diagrams of your system, kept current
- Decision records for every significant choice
- A scaling plan with the signals that trigger each step
- A running-cost model you can check against the bill
- Decision
- Store background jobs in PostgreSQL and run them with a small worker. No separate queue yet.
- Context
- Jobs are few, and each must commit together with the data it changes.
- Consequences
- One less system to run, secure and pay for. Enough headroom for this stage and the next.
- Revisit when
- Jobs need to fan out to other services, or queue depth starts to affect request latency.
04Cost
Infrastructure that costs what your usage costs.
Most products don’t need clusters, reserved servers or a platform team on day one. They need managed services that cost little when things are quiet and grow with real usage. We commit to capacity only when your numbers say so.
- The path we plan
- Provisioned for peak
- Pay per use
- Committed baseline
At this usage · Launch
Pay per use. Serverless and edge compute and managed databases scale to near zero, so a quiet month costs little and nobody pays for idle servers.
- Provisioned for peak
- Pay per useLowest here
- Committed baseline
Bars are relative to each other at this point on the curve.
Eight levers we pull on every system.
Scale to zero
Idle environments and quiet services cost close to nothing when nobody is using them.
Managed, not self-hosted
No databases, queues or clusters you’d have to staff. The provider does the undifferentiated work.
One database until two pay off
PostgreSQL handles jobs, search and documents well into growth. Every extra datastore is another bill and another page at 3 a.m.
Cache at the edge
Cacheable responses are served close to the user, so origin compute and bandwidth stay small.
Right-size from real metrics
Instance sizes and limits come from measured load and are reviewed monthly, not guessed at launch.
Commit only to a proven baseline
Reserved capacity and savings plans come after months of steady usage, never before.
Tag every resource
Each cost maps to a product, an environment and an owner, so the monthly review can act on it.
Affordable observability
Sampling, sensible retention and log levels keep monitoring from becoming the largest line on the bill.
These follow the cost optimization principles of the AWS Well-Architected Framework, among them “adopt a consumption model” and “stop spending money on undifferentiated heavy lifting”, and apply on any cloud.
05Deliver
Every change passes the same gates.
Small changes, reviewed and tested, released in a way that can be reversed. It takes longer to set up than skipping it, and it is much faster from the second month on.
04 · Automated checks
The pipeline blocks the merge when anything fails.
- Test suites
- Dependency and secret scanning
- Static analysis
- Accessibility checks on interfaces
Measured, not claimed.
We set up DORA’s four keys for your system, so you can see delivery health rather than activity. From Google Cloud’s DevOps Research and Assessment program.
01
Deployment frequency
How often changes reach production. Small and frequent beats large and rare.
02
Lead time for changes
How long a commit takes to reach users.
03
Change failure rate
How often a release needs a fix or a rollback.
04
Failed deployment recovery time
How quickly service is restored when a release goes wrong.
You’ll always know where things stand.
- Weekly, in writing
- What shipped, what’s next and what’s at risk. Short enough to read, specific enough to act on.
- Working software, every increment
- You see it running in a real environment, not in slides.
- Decisions written down
- Architecture decision records for anything you’d otherwise have to ask about in a year.
- Problems raised early
- Risks, delays and trade-offs surface when they appear, with options, not at the end of a phase.
06Maintain
Software is never finished. It is cared for, or it decays.
Real-world software has to keep adapting as everything around it changes, and it grows more complex unless someone does the work to keep it simple. That work is small, regular and unglamorous. We put it on a calendar.
“A system must be continually adapted or it becomes progressively less satisfactory.”
| Recurring work | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Security patches and dependency updatesKnown vulnerabilities are fixed while they are still small. | Every week | Every week | Every week | Every week | Every week | Every week | Every week | Every week | Every week | Every week | Every week | Every week |
| Written care reportWhat changed, what we saw and what we recommend next. | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled |
| Cost and usage reviewRight-sizing and waste removal, before the bill grows quietly. | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled | Scheduled |
| Backup restore testA backup nobody has restored is a hope, not a plan. | Scheduled | Scheduled | Scheduled | Scheduled | ||||||||
| Access reviewPeople and services keep only the access they still need. | Scheduled | Scheduled | Scheduled | Scheduled | ||||||||
| Framework and runtime upgradesSmall, planned upgrades instead of a forced rewrite later. | Scheduled | Scheduled | ||||||||||
| Architecture and roadmap reviewIs the system still shaped for where the business is going? | Scheduled | Scheduled | ||||||||||
| Threat model refreshNew features and integrations change what an attacker would want. | Scheduled | |||||||||||
| Disaster recovery drillRehearsed recovery, timed, with the runbook updated afterwards. | Scheduled |
A typical plan. We shape the calendar to your system, your traffic and your compliance obligations.
07What you keep
Every stage leaves you something to keep.
01 · Design
Decide what to build, and why.
- Product brief
- Clickable prototype
- Architecture decision records
02 · Engineer
Build it in small, working increments.
- Source code in your repositories
- Test suites
- Weekly written updates
03 · Integrate
Connect it to everything it depends on.
- API contracts
- Integration tests
- Failure-mode notes
04 · Secure
Make security a property, not a phase.
- Threat model
- Access map
- Security review notes
05 · Scale
Prepare it for the load you expect, and the load you don’t.
- Infrastructure as code
- Dashboards and alerts
- Capacity plan
06 · Maintain
Keep it healthy for years, not weeks.
- Runbooks
- Upgrade calendar
- Handover documentation
08Work together
Four ways to work together.
Choose by the problem, not the contract type. Most relationships start with a first step and grow from there.
Fits when
When the problem is real but the shape of the answer isn’t clear yet.
How it runs
Two to four weeks, a fixed price and a defined deliverable: a product brief and architecture, a codebase assessment, or an AI go/no-go with evidence.
Billed
Fixed price
You get
- A product brief, assessment report or AI go/no-go
- Architecture options and the main risks
- A range for the next stage, with its assumptions
09Ownership
Everything stays yours. From day one.
Your repositories
Code lives in your GitHub, GitLab or Bitbucket organization from the first commit.
Your cloud accounts
Infrastructure is created in accounts you own; every credential is handed back at the end.
Your intellectual property
Work product is assigned to you under the agreement. Any tools we bring are licensed to you for use with it.
Your documentation
Runbooks, decision records and handover notes are delivered as the work happens, so nothing depends on our memory.
10Commitments
What you can hold us to.
We can’t show you a decade. We can show you the terms we work to, and where each one is written down.
- 01
Your code lives in your repositories from the first commit.
We work in your GitHub, GitLab or Bitbucket organization. Nothing important lives only on our machines.
- 02
Your infrastructure stays in your accounts.
Cloud resources are created in accounts you own, and every credential is handed back when we finish.
- 03
You own what we build.
Intellectual property is assigned to you under our agreement. No proprietary framework you have to rent back.
- 04
Every stage leaves something you keep.
Decision records, runbooks and documentation are delivered as the work happens, not promised for the end.
- 05
You will always know where things stand.
A written update every week: what shipped, what’s next and what’s at risk. Problems are raised early, in writing.
- 06
Security is part of done.
Least-privilege access, reviews and dependency scanning on every engagement: before launch, not after an incident.
- 07
We will tell you when the answer is no.
If AI, a rewrite or a new service is the wrong tool for your problem, we say so and explain why.
11The stack behind it
211 technologies, across every layer of the system.
- TypeScript
- React Native
- Next.js
- Swift
- Kotlin
- Node.js
- Python
- Go
- PostgreSQL
- Redis
- Google Cloud
- Cloudflare
- Docker
- Kubernetes
- Terraform
- MQTT
From 11 layers: interfaces, services, data, AI, cloud, delivery, security, integrations and connected devices.
12Questions
The practical ones.
A first step takes two to four weeks. Product builds usually run in increments of two weeks over a few months; care retainers run as long as the system does. We give you a range after discovery, not before.
First steps are fixed-price. Builds are estimated as a range and billed on time spent, with the assumptions written down. Retainers are a fixed monthly scope. We don’t fix prices for poorly understood work, because that only hides the risk.
Yes. We can own a product end to end, build alongside your engineers, or take on a subsystem behind a clear interface. We work in your tools and rituals.
Our studio day runs on UTC+05:30, and we plan a daily overlap window with your team. Most communication is written, so work continues cleanly across the gap.
Yes. We sign an NDA before discovery if you prefer, and we work within your security policies, identity provider and tooling. See Security and Compliance.
Only with your agreement and under your policies, through company-managed accounts on plans that don’t train on inputs, with every change reviewed by an engineer. See Responsible AI.
That’s the point of everything living in your accounts with documentation as we go. We plan the handover with your team and stay available while it settles.
Start a conversation
Want to start with a small, fixed first step?
Tell us the situation. We’ll suggest the first step that would tell you the most.