Boring choices,
on purpose.
We build on mainstream, well-documented technology so that your next developer is easy to hire and not dependent on us. Novel stacks are fun to write and expensive to inherit.
What we build with,
and when.
Final choices are made in the validation sprint against your requirements, your team's existing skills and what you will need to hire for later.
Web application
- React with TypeScript
- Next.js where SEO or SSR matters
- Tailwind or CSS modules
- Component library, documented
Application & API
- Node.js with TypeScript, or Python
- Laravel / PHP where the team or product suits it
- REST by default, GraphQL where it earns its keep
- Background jobs and queues
Storage
- PostgreSQL as the default
- MySQL where you already run it
- Redis for cache and queues
- Object storage for files and media
iOS & Android
- React Native or Flutter
- Native where the product genuinely requires it
- Store submission handled for you
- Over-the-air update capability
Cloud & deployment
- AWS, Google Cloud, Azure or DigitalOcean
- Containerised where it helps, not by fashion
- CI/CD on GitHub Actions or GitLab
- Three environments as standard
Running it
- Uptime and error monitoring with alerting
- Structured logging and log retention
- Automated backups with restore testing
- Secrets management, never in the repository
Six rules we apply
to every build.
Not because they are fashionable, but because each one is a lesson from a product that was expensive to fix later.
- Start with a monolith. Microservices solve an organisational problem you do not have at launch, and add operational cost you cannot yet afford.
- Model the data before the screens. Interfaces are cheap to change; a wrong data model is the most expensive mistake in software.
- Make configuration data, not code. Rules, limits and thresholds your team will want to change should not require a deployment.
- Log anything consequential. Money, permissions and data changes get an audit trail from day one, because retrofitting one is painful.
- Design for the boring failure. Third-party outages, failed payments, partial data and duplicate submissions are normal, not edge cases.
- Cost-check the architecture. A design that works but costs more to run than the product earns is a failed design.
Taking over
someone else’s build.
Common, and rarely as bad as the last developer's departure made it feel. We start with a paid technical audit rather than a promise, because the honest answer is sometimes that rebuilding costs less than rescuing.
Ask for an audit →The audit is yours regardless of what you decide afterwards, and its fee is credited against a build engagement started within sixty days.
Bring us the idea. We’ll bring back a scope you can hold us to.
A scoping call costs nothing and takes forty-five minutes. If the product does not need building yet, or needs building by someone else, we would rather say so in that call than three months into a contract.