Government and public sector
We build and run a system for the Central Taxes Survey Zone under the Government of Bangladesh, at taxsurvey.gov.bd. Public-sector work has requirements that arrive before the brief does — procurement, accessibility, audit and handover — and they shape the build rather than decorate it.
Talk about scopeWhat this work actually demands
Procurement decides the architecture
Where it runs, who may hold the data, which browsers must work and what happens at handover are all fixed before a line is written, and usually by a document rather than a conversation. Treating those as constraints from day one is the difference between a system that passes review and one that is rebuilt after it.
Every action is answerable to someone
Public bodies are asked, sometimes years later and sometimes formally, who did what and on whose authority. That makes an append-only audit trail and a real approval chain part of the foundation rather than a reporting feature — and it is the same spine we build into every system, which is why it costs us little to meet here.
It has to work for everyone, on anything
A public system cannot choose its users. That means accessibility as a requirement rather than an audit item, and pages that work on old devices and thin connections — which is a performance and markup discipline, not a settings page, and one that has to be there from the start.
Append-only is not a reporting feature bolted on at the end. It is a decision about the schema, made before the first screen is drawn, and it is the same spine every system we build carries — which is why it costs us little to meet here.
Public-sector scope is written down before it is priced
Send us the requirementWhen not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.