Custom software for the problem you actually have.
Software built around how the work is already done, shipped in a version small enough to be wrong about, and still supported by us three years later.
- 01Business problem
- 02Engineering approach
- 03Software solution
- 04Business result
In productionTerminal and port operations software running in a live container terminal, and city parking in Motijheel, Dhaka, with Dhaka South City Corporation.
Problems we solve
None of these is a technology problem when it arrives. All of them become one by the time somebody calls us.
The process lives in one person’s head
The business runs, and it runs because somebody remembers the exceptions. That works until they take a week off.
Three systems, three answers
Every department has a number and none of them agrees. The reconciliation meeting is the real system.
The spreadsheet that became infrastructure
It started as a workaround and now the month-end close depends on it. Nobody is willing to touch it.
A product that cannot change direction
Version one shipped, the market moved, and the architecture will not bend. Every change is quoted as a rewrite.
How the work is actually done
The plan for this page lists these as separate sections. They are separate disciplines and one engagement, which is why they read as one list.
Architecture
Written down and signed by a named engineer before the build starts. The document says what the system is not allowed to do, which is the part that decides everything else.
Backend engineering
The data model first. Most of what makes a system disagree with itself is a second copy of a definition somebody needed on a Tuesday.
Frontend engineering
Built for the person who did not choose the software and cannot close the tab. What a screen may show while a write is in flight is a design decision, not a loading state.
API development
Versioned, documented, and designed on the assumption that something we do not control will call it badly.
Integrations
The other system will go down, return the wrong shape, or answer slowly. All three are designed for rather than discovered.
Database engineering
Constraints in the database, not only in the application. An invariant enforced in one place is an invariant.
Security
Access control modelled against roles that exist in the business. Reviewed by a person before every release, never by a model alone.
Performance
Measured at the hour the system is least forgiving, because that is the hour it is judged at.
What we build
Systems people use for eight hours a day, in environments that do not pause for a release.
Operational platforms
The system the business runs on: production, inventory, movement, scheduling, billing.
SaaS and multi tenant products
One codebase, many customers, and configuration that keeps them from becoming forks.
Internal tools
The unglamorous software that removes a manual step somebody does four hundred times a month.
Integrations
Making two systems that were never designed to meet agree on one record.
Customer facing applications
Where the operator’s record and the customer’s view are the same record, not two copies.
MVPs that survive
The smallest version that answers the real question, built so version two is a change rather than a restart.
What we build it on.
Grouped by what it does rather than shown as a wall of marks, and short enough that your own team can judge whether they could take it over.
- Frontend
- ReactTypeScriptNext.jsDesign systems
- Backend
- PythonDjangoFastAPINode.js
- Data
- PostgreSQLMySQLRedisData modelling
- Cloud
- AWSDockerCI/CDInfrastructure as code
- Operations
- Metrics and tracingAlertingLog aggregationRelease automation
Work we have done under this line.
Derived from the engagement record rather than listed here, so this section cannot claim work that is not in it.
Public SectorMotijheel, Dhaka
Dhaka South City Corporation
End-to-end digitisation of parking operations, with real-time space utilisation and vehicle movement.
LogisticsLive container terminal
A container terminal operator
Real-time yard, gate and equipment visibility in one operational view, under continuous operational demand.
Real EstateDhaka
A multi-tower estate operator
Property operations and resident experience on one platform.
Retail
Classic Cut Boutique Salon
Salon POS running haircuts, treatments, beauty services and product sales through one connected system.
Questions we get asked.
The objections specific to this line, answered here rather than in a first call.
How small can the first release be?
Small enough that being wrong about it costs weeks rather than a year. The point of the first release is to replace an assumption with evidence about what people actually do, and a large first release buys less of that than a small one.
Do you work from a specification, or write one?
Either. If you have a specification we will read it and tell you which parts we think are wrong before we quote it. If you do not, discovery produces one, and the architecture document that comes out of it is signed before the build starts.
What happens to a project when priorities change mid-build?
The architecture is written to expect it. Work moves between gates continuously and stops at three of them, so a change of direction lands at a gate rather than in the middle of a half-built assumption.
Where to go next
You do not need to arrive with a perfect technical specification.
Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.
Start your build