MSME operations
Business software for small enterprises
Eluno is a working name used for this write-up. The client isn't identified, so their actual product name isn't either.
Business software for a small enterprise that had outgrown notebooks and WhatsApp but was never going to buy an ERP.
Interface built in code for this case study — not a client screen capture.
01Business problem
A small business at the point where the owner is the only person who knows what is owed, what is promised and what is late — and all three live in their head.
Who feels it
MSMEs do not run on nothing. They run on a WhatsApp thread per customer, a notebook for what was quoted, a spreadsheet somebody started and stopped maintaining, and an owner who remembers the rest. That arrangement is not stupid; it is genuinely faster than most software, right up until the volume passes what one person can hold.
The failure is never dramatic. A quote goes out and nobody follows it up. A delivery is promised twice for the same day. A customer pays half and the balance is remembered wrong. Each one costs a little money and some credibility, and none of them shows up as a problem you could point at.
The reason off-the-shelf software does not fix it is not price. It is that an ERP asks the business to describe itself in the ERP’s vocabulary before it will do anything useful, and a business with nine people cannot spare the weeks that takes. So the software is bought, half-configured, abandoned, and the notebook comes back.
02Product overview
One record per customer, one thread of what was quoted, agreed, delivered and paid — built around how the business already talks about its work, not around a chart of accounts.
Engineering notes
I started by writing down the vocabulary the owner used, unedited, and made that the schema. What they called an enquiry stayed an enquiry, not a "lead". What they called a job stayed a job, not a "work order". That sounds cosmetic and it is not: every renaming is a translation the user has to perform mentally on every screen, and those translations are the reason internal tools get abandoned.
The core is a single timeline per customer. An enquiry becomes a quotation, a quotation becomes a confirmed job, a job accrues deliveries and payments, and each of those transitions is a row you can point at with a date and a person attached. Nothing is edited in place — a revised quotation is a new version with the old one still readable, because "what did we actually agree" is the question that starts arguments.
The hardest part of the build was deciding what not to build. There is no accounting module, no inventory valuation, no user-configurable workflow engine. Each of those was asked about and each would have doubled the surface area for a feature that would be used quarterly at best. What went in instead was a payments view that answers "who owes us money, and how old is it" on one screen, because that was the question being asked daily.
I stayed deliberately close to the owner during the build rather than gathering requirements once and disappearing. Small-business software fails on details that never make it into a specification — that a customer has two phone numbers and one of them is the one that actually gets answered, that prices are agreed in round figures and adjusted verbally, that "delivered" sometimes means delivered to a relative.
03Key features
7 capabilities. Every one of them is deterministic software — there is no model in this build, and nothing here is described as AI.
Every enquiry, quotation, job, delivery and payment for a customer on one page in date order. The answer to "where are we with them" is a scroll, not an investigation.
A revision creates a new version; the old one is never overwritten. Both stay readable, with who changed what and when, because a disputed price is only settled by the record.
What is owed, by whom, and how many days old — sorted by age, not by amount, because a small invoice that is ninety days late is the more urgent problem.
A payment is allocated against specific charges and never against a single balance, so the record shows which items are settled instead of only how much is left.
The states are the ones the owner already used out loud. No configurable workflow engine, because a nine-person business does not need to model its own process, it needs the process it has to be visible.
Quotations and receipts generate as clean documents with the business’s own details, because these get forwarded to customers and a spreadsheet screenshot undermines every impression the business is trying to make.
Built for a mid-range Android on mobile data first. The desktop layout came second, because the person entering a payment is standing up.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Captured against a customer with the minimum required to be useful. An enquiry with only a name and a phone number is a valid record, because a form that demands more gets abandoned mid-entry.
Line items with quantities and agreed prices, versioned on every revision. A quotation is immutable once a job is confirmed against it.
The agreed version is copied onto the job, not referenced, so a later revision cannot retroactively change what was agreed.
Deliveries recorded against job lines, partial by default. Most real deliveries are partial and software that assumes otherwise forces staff to lie to it.
Allocated against specific charges, oldest first by default with a manual override, so the ledger shows which items a part payment cleared.
A derived view, never a stored balance. Ageing is computed from the charge dates, so it cannot drift out of step with the underlying rows.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Every term the user has to translate is friction on every screen. Adopting their words removed the training problem almost entirely — nobody needed to learn what a screen was for.
Trade-off
The schema is specific to this business and would need renaming to serve another one. For a single client that is the right direction; it would be the wrong foundation for a product.
Why
The most expensive disputes in this business were about what had been agreed. Versioning turned that from a memory question into a lookup.
Trade-off
More rows and a slightly heavier interface — a quotation list has to show which version is current without burying the history that makes it useful.
Why
A single balance cannot answer "is that item paid for", and that is the question a customer asks when they dispute one line of five.
Trade-off
Allocation needs an interface and a default order, and the default is occasionally wrong — so it is overridable, which is one more thing to explain.
Why
The business already had an accountant and a process that worked. Duplicating it would have created two ledgers that disagreed, which is worse than one ledger and a spreadsheet export.
Trade-off
Month-end still involves a manual step. That was an explicit decision with the owner, not an omission.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Cut required fields to the ones that make a record findable — a name and one contact route — and let everything else be filled in later from the record itself.
Outcome
Records started getting created at the moment of the phone call instead of "later". A system that lags a day behind the business is a different thing from one that reflects it.
Approach
Made the agreed line price an explicit field distinct from the list price, with the difference visible and not hidden, and carried the agreed figure onto the job at confirmation.
Outcome
Discounts stopped being invisible. The owner could see what had been given away without having to compare two documents by eye.
Approach
Cut the list views to the fields that get read, paginated on the server, and removed a client-side table library that was costing more than the data it displayed.
Outcome
The screens that get opened forty times a day became usable on mobile data — the only performance measurement that mattered here.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Customer timeline
Enquiry through to payment in one column, with each transition dated and attributed.
Quotation versions
The current version and the one it replaced, with the changed lines marked.
Outstanding
Sorted by age, because the oldest small debt is the more serious one.
Payment allocation
Which charges a part payment cleared, and what it left open.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
11Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.