The software is the last decision, not the first.
Most software fails because it was specified before anyone watched the work. Somebody described a process in a meeting, somebody else wrote it down as features, and the system that arrived matched the description rather than the job. We work in the opposite order.
Start with the problem, not the software
The order below is the whole method compressed into eleven words. Each stage is only answerable once the one before it has been answered, which is why it is a sequence rather than a list of activities that happen to co-occur.
The part people skip is the middle. Understanding a customer is easy to claim and cheap to do badly; understanding the workflow means standing in the room at the hour the workflow breaks. The job is what someone is trying to get done, which is rarely what they asked for. The root cause is the thing that, left alone, regenerates the problem after you have built the solution.
- Understand the customer
- Understand the context
- Discover the problem
- Understand the workflow
- Identify the job
- Find the root cause
- Design the solution
- Build
- Deploy
- Measure
- Improve
The first seven stages happen before a line of production code is written. That is not a preference — it is the gate below, and it is the reason the work either fits or does not.
What that means in practice
Ten steps, in order. Several carry a commitment — the sentence that turns a step from something we intend to do into something you can hold us to, and check.
- 01
Watch the work before writing anything down
Eight shadowing sessions with the person who actually owns the problem, at the hour the problem happens — for a school coordinator, that is 07:00 to 08:30, because that is when the day breaks. Three predictions are written down before the first session: how long dispatch takes, how often absences happen, and who really decides the cover.
We commit to this. The predictions are pre-registered, so they can be scored against what was observed rather than remembered favourably afterwards.
- 02
Score the predictions, then decide whether to build
The shadowing report is delivered and all three predictions are marked right or wrong. A prediction that was wrong is more useful than one that was right, because it is the one that changes the design.
We commit to this. No production code is written until that report exists.
- 03
Find the job, not the feature request
A request for a timetable module is usually a request to stop losing the first forty-five minutes of the day. The two produce different software. We separate what someone asked for from what they are trying to get done, and build for the second.
- 04
State the hypothesis so it can be killed
Each bet carries both a measure and a falsification threshold, agreed in advance. Substitution coverage reaching 80% by month three is the bet; below 50% the wedge is wrong and we say so rather than explaining the number away.
We commit to this. Any gate that fails twice kills or re-scopes the line. Three kill triggers are named in advance: no paid conversion at the pilot price, more than 35% of the codebase becoming customer-specific, or a payback period beyond fourteen months.
- 05
Scope to two jobs and refuse the rest
The first release of a product does one or two things properly. Everything else is written down as deferred, with the reason, so that it is a decision on the record rather than a thing that quietly did not happen.
- 06
Build against the worst phone and the worst day of the network
The performance budget comes from a four-gigabyte Android on a five-megabit connection with 200 ms of latency, not from the laptop it was written on. Capture works with no network for at least seventy-two hours and loses nothing when it returns.
We commit to this. Exceeding the JavaScript budget on a teacher or guardian path fails the build. It is a requirement, not a guideline.
- 07
Import before anything else, export from day one
Implementation failure, not licence cost, is what institutions actually fear. "Who enters 1,500 student records?" is the objection that kills deals, so bulk import with a dry run and a row-level error report is the first thing built — and a complete self-serve export is the second.
We commit to this. Every record you gave us and every record we created for you, in open formats, within fifteen minutes, without asking us.
- 08
Go live in ten working days, or say why not
Provision, import, structure, solve, train, fund the messaging wallet, configure fees, and reach a first unaided dispatch — with nobody from Nimikh in the loop on that last step. Institutions switch during term breaks, because a mid-term switch risks fee collection and exam publication.
- 09
Measure whether it does the work, not whether people log in
The number that matters is how many institutions ran a real substitution dispatch and recorded real attendance in a given week. Logins, page views, modules enabled and messages sent are explicitly not optimised — all four can rise while the product does nothing useful.
- 10
Publish the corrections
When our own arithmetic was wrong about where our pricing sat against local alternatives, the claim was withdrawn in the requirements document rather than quietly amended. A figure we cannot verify does not become a figure we use carefully — it stops being used.
What we will not do
A list of things a company can do costs nothing to write. This is the other list. Each entry closes off revenue, or a shortcut, or a claim that would make a page like this one more impressive — which is exactly why it is worth more than a feature table.
We will not hold your money
The institution stays merchant of record. Aggregating payments is a licensed activity in Bangladesh — a trust and settlement account, T+5 settlement, about BDT 1 crore of capital, and personal liability for named officers. We orchestrate collection; we never sit in the flow of funds.
We will not publish a false-alarm reduction figure
No independently audited figure exists for this class of system. We commit to the mechanism and to a baseline measured on your own cameras, at your own site. A percentage quoted before that is a claim about somebody else’s footage.
We will not quote a camera count before measuring your site
How many streams one box handles depends on resolution, frame rate, scene complexity and the accelerator fitted. Quoting it in advance is guessing with your capital.
We will not ship AI in a first release
Substitute ranking is rules-based, and payment matching is an honest exceptions queue rather than a probabilistic guess. A silent wrong match in a fee ledger is worse than a queue somebody has to work.
We will not bundle messaging into the subscription
A Bangla SMS is two or more parts at seventy Unicode characters each. Bundling would destroy the margin in the exact week fee deadlines and results land together, and the cost would come back as a worse product. It is prepaid, metered, and capped by you.
We will not sell you a tier we cannot serve properly
A band priced below the cost of supporting it was withdrawn rather than sold. An institution under three hundred students is served on the per-branch price or not at all.
We will not name you as a customer without your written permission
Every logo wall contains at least one company that did not agree to be on it. Ours has none on it at all, which is at least accurate.
None of these is a position we arrived at comfortably. Holding money would make collection simpler to sell. A false-alarm figure would make a security page far easier to write. A per-camera count would answer the first question every buyer asks. We do not have audited numbers for any of them, and a number borrowed from somebody else’s site is a statement about somebody else’s site.
If one of these refusals is the reason we are the wrong supplier for you, that is a better outcome than discovering it after a contract. We will usually know who is right for the job instead.
The same method on custom work
Nothing above is specific to our own products. A point-of-sale system, an inventory ledger, a school office or a booking engine gets the same sequence: watch the work, score the predictions, find the job, scope to two things, build against the worst phone, import first and export from day one.
And the engineering under it
Method decides what should exist. Engineering decides whether it survives a Bangladeshi network, a shared low-cost Android, a settlement file that arrives three days late, and a database holding more than one organisation’s records at once. Those decisions are written down with their rejected alternatives.
Start at step one
Tell us what goes wrong and when it goes wrong — the hour, the person it lands on, and what it costs when it does. That conversation is the beginning of the sequence above, and it is free.