Most companies that buy a business system buy it from a demo, and the demo was built to look good rather than to look like your company. So you end up owning a system that does everything except the one thing that eats half your team's week. This article is written from the other direction: what each sector actually needs, which screens matter, where the data model hides a trap that surfaces a year later, and what to build first.
What follows comes from systems I have built and delivered, and from systems handed to me to rescue after someone else built them. The second kind teaches more, because a failed system tells you precisely which question nobody asked at the start.
Why demos mislead you
A demo runs on clean data and one ideal path. Three clicks produce an invoice, two more produce a colourful report. None of that is a lie, but it leaves out everything that makes systems hard.
Your real business is made of exceptions. The customer who pays half in cash and half next month. The order that gets amended after confirmation. The employee who needs to see prices without being able to change them. The branch that keeps different hours in Ramadan. The supplier who sends a monthly statement as a spreadsheet in their own format. These are not edge cases. They are your business, and they decide whether the system gets used or abandoned.
The question I give every client after a demo they liked: ask them to enter your hardest case, not your easiest. One hard case reveals more about a system than an hour of presentation.
The four questions that define any business system
Before your sector comes into it, these four shape every business system, and the answers belong to you rather than to a developer.
What is the thing you are tracking?
Every business system tracks one primary thing and everything else hangs off it. In property it is the unit. In a clinic it is the appointment. In a law firm it is the matter. In delivery it is the shipment. In construction it is the line item in the bill of quantities. In training it is the enrolment.
Naming that thing precisely is the most important decision in the project, because everything else is attached to it. Systems that fail usually never named it, or named the wrong thing, which is why every report they produce needs manual arithmetic afterwards.
What states does it have, and how does it move between them?
The thing you track passes through states. A unit is available, then reserved, then sold, then handed over. An order is new, accepted, being prepared, out for delivery, then delivered or returned. Write those states on paper, write who owns each transition, and write what happens when it moves backwards.
Moving backwards is the part everybody forgets to specify and the part that causes the most real trouble. A delivered order comes back. A confirmed booking is cancelled after payment. A closed matter is reopened. If the reverse path is not designed, it will be performed by hand in the database, which is the worst thing that can happen to a system.
Who uses it and what can each of them do?
List the roles, give each one three to five things it does, and at least one thing it must not do. That last one is what gets forgotten, and it is the definition of permissions.
Avoid a common error: roles are not job titles. A branch manager and a sales manager may be the same role in the system, and one employee may hold two roles. Design roles around what gets done, not around who does it.
Which numbers do you want at the end of the month?
Start from the final report and work backwards. If you want margin per branch, the system has to record cost with every transaction rather than only price. If you want to know why you lose customers, there has to be a loss-reason field the user is made to pick from.
Thinking this way saves more than anything else, because adding a field at the start is free and adding it a year later means you own a year of incomplete data that cannot be recovered.
How to tell whether you need a system at all
Not every business needs one, and some of the companies that buy one needed to organise their process first. These are the signals I treat as sufficient.
- The same information is written in two or more places, and one of them is always out of date
- One person knows something essential and it is written down nowhere
- Answering a simple management question takes more than an hour of gathering
- The mistakes that cost you money keep happening for the same reason
- You do not know your numbers until two weeks after month end
- Growing means hiring someone for administrative work rather than productive work
- You have lost a customer or an order because nobody followed up
The first and the last are the strongest. Retyping data is a direct measure of hours wasted every week, and it can be calculated. Losing an order because nobody followed it is revenue leaking, and it is usually larger than the cost of the system.
And a counter-signal that says do not build yet: if your process itself is undefined and changes every month, programming it now sets confusion in concrete. Organise it on paper or in a spreadsheet until it settles, then build it. A system speeds up a process that exists; it does not create one.
The shared foundation under every business system
Before any sector-specific work, this structure exists in every system I have built, and it is close to half the effort. If someone hands you a quote that mentions none of it, they have not estimated a system.
Identity and permissions
Secure sign-in, roles, and permissions enforced on the server rather than hidden in the interface. Two-factor authentication for administrative accounts at minimum. And the ability to disable an account immediately when someone leaves, which is always forgotten and always matters at the worst possible moment.
A record of who did what
Every meaningful change recorded with who, when, and what the value was before. It looks like an optional extra until the first time you need to know who changed a price or deleted a record, and then it becomes the most important feature in the system. In anything holding money or personal data it is a requirement rather than a luxury.
A data model that expresses your business, not your current moment
The test is simple: can you open a new branch, add a service type, a currency, or a pricing plan, from the admin panel without a developer? If not, your model describes your situation today, and every bit of growth will be a project.
Notifications that earn their place
A system that waits for you to open it before you learn what happened is a system you will forget. The useful notifications are few and specific: an alert when a new enquiry arrives, a reminder before an appointment, a warning when a limit is crossed, and a daily or weekly summary that arrives by email or WhatsApp without anybody asking for it.
A rule I follow: every notification must be actionable. One that the recipient cannot act on will be ignored, and after ten of those the important ones get ignored with it.
Reports that get read
A small number of reports people actually open beats twenty that nobody does. Make them exportable, because the accountant or the investor will ask for a file however handsome the report is on screen.
Backups you have restored
Automatic daily backups, held somewhere other than the server itself, and someone has actually restored one. A backup nobody has tried restoring is not a backup, it is a hope.
Property and real estate development
The thing you track is the unit, and everything else hangs off it. The biggest mistake in this sector is building the system around the customer or around sales, which makes unit status a by-product of the last transaction instead of being the truth.
The real workflow
A unit is available, then a buyer reserves it with a holding deposit for a defined period, then either completes or the reservation expires and the unit returns to available automatically. Then a contract, then a payment schedule, then handover with a report and a snag list, then a warranty period. At every point something can change: a buyer transfers their contract, a contract is cancelled, two units are merged.
The screens that matter
The unit inventory screen with clear colour-coded status is the one your sales team will open twenty times a day, so invest in it. Then the payment schedule for a single buyer, showing what has been paid and what is late. Then commissions, because they cause half the internal disputes in property companies. Then handover, with a checklist and photographs.
The data model trap
A reservation has to be an entity with a duration that expires on its own, not a status on the unit that a person changes by hand. I have seen more than one property system where units get reserved and nobody ever releases them, so half the inventory is frozen on paper while being available in reality. The rule: anything with a duration needs an expiry date and a scheduled job that acts on it.
What to build first
Unit inventory, reservations, and the payment schedule. Commissions, handover and warranty are phase two. The public project site is a separate project and can come before or after, but it must read unit status from the same system rather than from a manually updated file.
Property management and rentals
Adjacent to the above and completely different in its model, because the thing tracked here is not the unit but the lease. A lease has a start, an end, a value, recurring payments and a renewal, and the unit is merely an attribute of it.
The real workflow
A vacant unit, then a viewing, then a lease with a term and cheques or instalments, then recurring collection, then maintenance requests from the tenant, then renewal or move-out with a deposit settlement. The part that consumes time in reality is not complexity but repetition: dozens of leases with amounts due in the same week.
The screens that matter
A board showing what is due this month and what is overdue, which pays for the system on its own. A list of leases expiring within sixty days, because a late renewal means an empty month. And maintenance requests with their status, because a tenant who can see their request being handled renews more often.
The data model trap
Store payments as a separate schedule of instalments rather than as fields on the lease. Annual increases, deferrals, partial payments and move-out settlements all need a record per payment. Systems that store an annual value and one cheque number break the first time a tenant pays in uneven amounts.
What to build first
Leases, the collection schedule, and the alerts. Maintenance requests and a tenant portal are a useful phase two but they do not repay the cost as quickly as collection does.
Law firms and legal practices
The thing tracked is the matter, and confidentiality in this sector is not a feature but the architecture. The first decision in the project is not a screen design, it is who can see what.
The real workflow
An enquiry arrives, then a conflict check and a preliminary assessment, then a fee proposal, then a signed engagement, then work on the matter with documents, hearings and statutory deadlines, then billing either hourly, by stage or at a fixed fee, then closure and archiving with a retention period.
The screens that matter
Upcoming statutory deadlines, because missing one in this sector is not an administrative slip but a liability. The single-matter view with every document and its whole history in one place. And unbilled time, which is the revenue firms forget to collect.
The data model trap
Permissions have to work at matter level, not at system level. A lawyer has full rights on their own matters and none on a colleague's, a partner sees everything, a trainee sees only what was assigned. That is an architectural decision made at the start, and converting a system with global permissions into one with record-level permissions is work that approaches a rebuild.
A second trap sits in the public intake form. Everything a prospective client types is in your possession from the moment they submit it, including details the firm may prefer not to hold before an engagement exists. Collect only enough to assess, and document a retention period for what never becomes an engagement.
What to build first
Matter management, documents and statutory deadlines. Hourly billing is phase two unless it is your primary model. The public platform with a service tree is an independent project that generates the enquiries, and it usually pays back sooner.
Clinics and healthcare
The thing tracked is the appointment, and patient data raises the security floor for the whole project without argument.
The real workflow
A patient looks for a time, so they must see real availability rather than a fixed list of slots. Then they book, a confirmation arrives, and a reminder before the appointment. Then attendance or a no-show, and no-shows are the largest financial leak in clinics, reducible with reminders and a deposit. Then the visit, then a record updated, then a follow-up or a next session.
The screens that matter
The day view for reception, with every appointment today, its status, and one button per action. That single screen decides whether the system gets used. Then the practitioner's calendar. Then the patient record with its history.
The data model trap
A room is a resource separate from a practitioner. An appointment needs a practitioner, a room and a duration, and availability is the intersection of all three. Systems that book against the practitioner alone will put two patients in one room, and this happens in the first week of operation. Add to that the fact that procedure duration varies: a cleaning is thirty minutes and an implant is two hours, so duration is an attribute of the service type rather than a constant in the system.
What to build first
Booking, availability and reminders, which pay for themselves on reduced no-shows alone. Patient accounts, online payment and reporting are phase two. Any integration with an existing clinic system needs to be investigated before pricing rather than after, because it is usually the largest single line item.
Education and training
The thing tracked is the enrolment, and the fundamental split in this sector is between selling to individuals and selling to companies. That split changes the system more than any feature does.
The real workflow for individuals
A learner enrols in a programme, pays or pays in instalments, attends or watches, progresses and is assessed, and receives a certificate. The corporate path is different: a company buys seats, allocates them to employees, tracks its team's progress, requests a report for HR, and is invoiced once rather than per learner.
The screens that matter
The instructor's screen has to be very simple, because an instructor who finds the system annoying will go back to a spreadsheet and learner progress will be lost. Then group progress for the corporate client, which is what renews contracts. Then certificates, with a verification an employer can use.
The data model trap
Separate the programme from the session it is offered in. The programme is content and a description; the session has a date, an instructor, a seat count and a price. Systems that merge the two cannot run the same programme twice at different prices or with different instructors without duplicating all the content, and after a year you have forty copies of the same description and one update means forty edits.
Separate the learner from the buyer too. Whoever pays is not always whoever attends, and that is the essence of corporate selling. OGS Academy showed this clearly: its clients are oil, gas and heavy industry companies buying accredited training for their teams, so the system is built around the company and the cohort rather than around the individual.
What to build first
Programmes, enrolment and payment. Assessment, automated certificates and the corporate layer come after, unless corporate selling is your primary model, in which case start there.
Restaurants and food service
The thing tracked is the order, and the economic driver in this sector is clear and calculable: the commission delivery marketplaces take from every order.
The real workflow
A customer opens the menu, chooses and customises, picks delivery or collection, pays or chooses cash on delivery, the order reaches the kitchen, is prepared, leaves, and is delivered. The underestimated part is the gap between an order arriving and reaching the kitchen: if it depends on someone watching a screen, you will lose orders at peak time.
The screens that matter
The kitchen display, with large type, an audible alert and one button per state. It is the least attractive screen and the most important one. Then the menu in the admin, so a manager can take a sold-out dish offline from their phone in two seconds.
The data model trap
Modifiers and extras have to be modelled the way the kitchen works, not the way the menu looks. Size, spice level, paid additions, free substitutions, some mandatory and some multiple choice. And a modifier group has to be reusable across dishes, or updating the price of one addition becomes an edit across thirty items.
A second trap: opening hours and their exceptions. A restaurant closes at a time, keeps different hours in Ramadan, and shuts a day for maintenance. Make the exception an entity the manager adds, not a change in the code.
What to build first
The menu, ordering, the kitchen display and delivery zones. Loyalty, an app and customer accounts are phase two, funded by the commission saved. I built exactly this order for a restaurant, and deferring those three was the reason the project worked rather than a gap in it.
Retail and distribution
The thing tracked is stock movement, not the product. A product is a fixed definition; the truth your business needs is how much of it, where, and why that changed.
The real workflow
Purchase from a supplier, receipt into a warehouse in a quantity that may differ from the purchase order, distribution to branches, then a sale, a return, damage, or a stock count that reveals a discrepancy. Each of those is a movement that has to be recorded with its reason, and the sum of them is the balance.
The screens that matter
Multi-branch stock levels. Products about to run out, calculated from sales rate rather than a fixed threshold. And stock count discrepancies, because that is where real operational problems surface.
The data model trap
Do not store the balance as a number you adjust. Store the movements and calculate the balance from them. A directly adjusted number loses reconciliation the first time a mistake happens, and there is no way to find where it diverged. Movements let you ask the system why the balance is ten and get a list back.
Separate the product from the variant too. A blue shirt in large is not a separate product but a variant, and merging the two makes every sales report meaningless.
What to build first
Products, movements, balances and stock counts. Purchasing and purchase orders next, and integration with a point of sale or an online store third, on the condition that stock is the single source of truth for every channel.
Logistics and delivery
The thing tracked is the shipment, and the item that surprises everybody is cash on delivery, because it turns a tracking system into a financial one.
The real workflow
A shipment is registered, assigned to a driver, collected, attempted, and then succeeds or fails for a reason. If it fails it is reattempted or returned. With cash on delivery the driver is carrying money that has to be settled at the end of the day. The reattempt is the case forgotten in design and very common in reality.
The screens that matter
The driver app, which has to work on a bad connection and save the action locally to send when connectivity returns. That is not an enhancement but a basic requirement, since drivers deliver in basement car parks and areas with weak coverage. Then the dispatch screen for the supervisor. Then driver cash settlement.
The data model trap
A delivery attempt is an entity independent of the shipment. One shipment may have three attempts, each with its own time, driver, failure reason and location. Systems that put a single status on the shipment lose the attempt history, which is exactly what you need in a dispute with a customer or when measuring a driver's performance.
Cash needs an explicit financial model: driver float, collection, remittance, and the difference. Tamem, an Upper Egypt delivery and logistics platform, carried all of this alongside its own Android app, and the lesson from it is that the financial part is bigger than the tracking part even though it is less prominent in a demo.
What to build first
Shipments, dispatch, the driver app and proof of delivery. Live customer tracking, zone-based pricing and store integrations come after.
Construction and engineering projects
The thing tracked is the line item in the bill of quantities, not the project. Everything financial and everything about time in this sector is measured at line-item level: progress, the payment application, actual cost, the variation.
The real workflow
A contract with a bill of quantities, then progressive execution by percentage, then a periodic payment application submitted and either approved or reduced, then a payment after retention and advance deductions. In parallel, variation orders that add or remove items, plus purchases, subcontractors and daily costs.
The screens that matter
Actual progress against planned, because the gap between them is a delay before it becomes a problem. Then the single payment application showing submitted against approved. Then actual cost against estimated per line item, which tells the owner whether the project is profitable before it ends rather than after.
The data model trap
A variation order has to be a new version of the bill of quantities, not an edit to it. Preserving the original matters because every claim or dispute goes back to what was agreed at the start. Systems that edit the bill in place lose the ability to prove anything.
What to build first
The bill of quantities, progress percentages and payment applications. Actual cost, purchasing and subcontractors are phase two, and they are what turns the system from tracking into profitability management.
Pilgrimage, umrah and travel
The thing tracked is the booking, and the engineering particularity of this sector is that demand follows the calendar and concentrates into very short windows.
The real workflow
A package is listed with its components, a customer books for a number of people, pays in full or in part, components are confirmed with suppliers, a component may change after confirmation, documents are issued, and the trip runs in stages.
The screens that matter
The booking with its travellers and their documents, because a missing document for one person holds up the group. Then components and their confirmation status with each supplier. Then payments, because partial payment is the rule in this sector rather than the exception.
The data model trap
Store the package components on the booking itself rather than as a reference to the package. If a hotel in the package changes next year, it must not change retroactively in last year's bookings. This is one of the most common errors I have seen in this sector's systems, and its effect is that your historical records quietly become wrong.
A second, technical trap: order state has to be designed for an unreliable network. A user in the Haram on a congested connection may submit twice or lose the connection before seeing the result. So every financial operation needs a key that prevents duplication, and every screen needs to tell the user their true state when they come back. I have built in this sector for Hadiah, Taffweed, Maeyn and Wasiila, and the lesson repeats in all of them.
What to build first
Packages, booking, payments and documents. Supplier management, itinerary management and a partner API come after.
Consultancies and professional services
The thing tracked is the opportunity, and the value in this sector is not in managing the work but in what happens to an incoming enquiry in its first hour.
The real workflow
An enquiry arrives, is classified and assigned, is contacted, is assessed for whether it deserves a proposal, a proposal goes out, it is won or lost with a recorded reason, then delivery in stages with outputs, then billing.
The screens that matter
New enquiries nobody has followed up, which is where you find lost revenue from day one. Then opportunities with their stage and value. Then loss reasons, which is the cheapest improvement tool you own if you use it.
The data model trap
Force a loss reason from a defined list rather than a free-text field. A free field gets left blank or filled with "not interested", which means nothing. A defined list gives you actionable information after three months: that you lose on price, or on timing, or on a scope you do not offer.
What to build first
Enquiry capture, routing and follow-up. And a note from the Sigma PMO project: when the output itself is the product, as in governance work and studies, the system needs an explicit approval layer so that nothing reaches a bank or an investor before a named person has signed it off. Automated analysis, human approval, and that order is not reversed.
Field service and maintenance
The thing tracked is the work order, and the difference from delivery is that the technician stays on site for a period and consumes parts.
The real workflow
A customer reports a problem, a work order opens with a priority, it is scheduled to a technician with a matching skill and an available slot, they travel, they diagnose, they may need parts they do not have, they complete or schedule a second visit, parts and hours are recorded, and it is invoiced or deducted from a maintenance contract.
The screens that matter
The scheduling screen by skill and area, because sending a technician without the right skill costs a whole visit. Then the technician app with a checklist, photographs and a customer signature. Then maintenance contracts and what has been consumed from them.
The data model trap
A visit is an entity separate from the work order. One work order may need three visits, each with a technician, parts, hours and an outcome. Anyone who makes the work order and the visit a single thing cannot measure how often the problem was not fixed on the first visit, which is the most important performance measure in this sector.
What to build first
Work orders, scheduling and the technician app. Inventory, maintenance contracts and invoicing come after.
Gyms and sports clubs
The thing tracked is the membership, which is a renewing contract rather than a sale, and that difference shapes the whole system.
The real workflow
A visitor takes a trial session, subscribes to a plan with a term, checks in, may freeze or transfer the membership, attends classes with limited capacity, then renews or lapses. Lapsing is the enemy here, because acquiring a new member costs several times what keeping one does.
The screens that matter
Members who have not attended for two weeks, because intervening at that point prevents a non-renewal. Then upcoming renewals. Then class booking against capacity.
The data model trap
A freeze has to be an entity with a period that extends the membership automatically, not a manual edit to the end date. A manual edit means somebody will forget, and a dispute with a member will have no record behind it.
What to build first
Memberships, renewals and check-in. Class booking, personal training and an app come after.
Charities and non-profit organisations
The thing tracked is the case or the beneficiary, and the fundamental difference from the commercial sector is that transparency is a required output rather than a side effect.
The real workflow
A beneficiary applies, eligibility is assessed against criteria and documents, it is approved for an amount or a service, it is disbursed, and the impact is documented. In parallel, donations arrive, some of them restricted to a specific programme and not permitted to be spent elsewhere.
The screens that matter
Applications with their stage, because transparency towards the applicant cuts phone calls. Then restricted donations against what has been spent from them, which answers the donor's question. And an impact report you can publish.
The data model trap
A restricted donation is a financial constraint, not a tag. The system has to be able to prevent spending from one programme's balance on another, and to show the remaining balance per restriction. Systems that treat the restriction as a text note cannot produce the report the donor asks for, which is the only report that matters.
What to build first
Applications, assessment, approval and disbursement. Donation management and impact reporting are a phase two tied directly to it.
Schools and nurseries
The thing tracked is the student within an academic year, and the fundamental difference from training is that the parent is a third party who needs their own screen and communicates a great deal.
The real workflow
An application, then an interview or assessment, then acceptance and enrolment into a class, then fees in instalments, then attendance, grades and behaviour, then periodic reports to the parent, then promotion to the next year or a transfer out.
The screens that matter
The parent screen is the most important one in the system and it measurably cuts calls to the office: their child's fees, attendance, grades and notifications. Then collections for the administration. Then the teacher's screen for entering grades and attendance in as few taps as possible.
The data model trap
Make the academic year a primary entity in the model. A student is not in a class; a student is enrolled in a class in a specific year. Systems that put the class as a field on the student cannot keep history or produce an academic transcript, and they break at the first promotion at year end.
Separate fees from enrolment too: sibling discounts, scholarships, and additions such as transport and uniform are all line items on the student's account rather than fields on the application form.
What to build first
Enrolment, fees and the parent portal. Grades, behaviour and academic reports are phase two unless they are required from day one.
Salons, aesthetics and spas
Close to medical clinics and different in two respects: the service is tied to a specific person the customer asks for by name, and promotion is part of the system rather than outside it.
The real workflow
A customer books a service with a named staff member, arrives, the service is performed and services may be added on the spot, they pay, they are enrolled in a loyalty scheme or a prepaid package, and they are reminded of a follow-up.
The screens that matter
The day view per staff member with their calculated commission, because commission is what makes staff enter data accurately. Then prepaid packages and what has been consumed. Then customers who have not returned in sixty days.
The data model trap
A prepaid package is a financial liability, not a points balance. Ten sessions paid up front means deferred revenue recognised with each session, and any system that only counts sessions without the financial side produces wrong numbers in the accounts. Add an expiry date and a clear rule for what happens after it.
What to build first
Booking, staff, commissions and packages. Reminders, loyalty and retail come after.
Car dealerships and workshops
A sector with two tracked things rather than one: the vehicle in the showroom, and the work order in the workshop. Anyone who tries to merge them early gets a system that is poor at both.
The showroom
The vehicle is an entity with a chassis number, specifications, a purchase cost and a date of entry, which is what makes margin per vehicle calculable. The workflow: into stock, listed, enquiries, test drive, negotiation, then sale or trade-in, then transfer of ownership and finance.
The model trap here: a trade-in is two transactions, not one. A vehicle sold and a vehicle bought at an estimated price, each needing its own record, or the profit on either becomes impossible to establish.
The workshop
Close to field service, with the difference that the vehicle comes in and stays. The workflow: intake with an initial inspection and photographs, diagnosis and a quote, customer approval, work with parts and hours, testing, handover.
The customer approval screen prevents half the disputes in this sector. Make it a link the customer opens on their phone and approves specific line items in, with the record retained.
What to build first
Whichever one is your primary business. If it is both, build the workshop first, because its daily throughput is denser and the effect of a system is felt sooner.
Hotels and serviced apartments
The thing tracked is the night, not the booking, and this is the distinction that trips up anyone who has built booking systems before.
The real workflow
A search with two dates, then availability and a price that varies by season and day, then a booking with a guarantee or a payment, then arrival, then a stay that may extend or shorten, then departure, then cleaning and preparing the unit for the next guest.
The screens that matter
Today's arrivals and departures. Then unit status by cleanliness and readiness, because a clean room not recorded as clean is an empty night. Then seasonal pricing.
The data model trap
Availability is calculated per night rather than per booking, and price is an attribute of the night too, because a five-night stay may carry three different rates. Anyone storing a single price on the booking cannot extend a stay or apply a seasonal rate correctly.
What to build first
Availability, booking, seasonal pricing and the arrivals board. Housekeeping and channel integration come after, and the second matters but do not start there before your own availability is correct internally.
Pharmacies and medical supplies
The thing tracked is the batch, not the product, because expiry date and batch number are not details here but the essence of the business.
The real workflow
Purchase in batches each with an expiry date, storage, a sale that must dispense the nearest expiry first, monitoring of what is approaching expiry so it can be returned or moved, and disposal of what has expired with a record.
The screens that matter
What expires within ninety days, ordered by value, because that turns a potential loss into a decision. Then shortages. Then supplier returns.
The data model trap
The balance is not a number on the product but the sum of its batch balances. Anyone storing a single balance per product loses the ability to know what expires and when, which is the most important piece of information in this sector. And it is not a decision that can be added later without rebuilding the whole inventory module.
What to build first
Products, batches, expiry dates and movements. Purchasing, returns and point-of-sale integration come after.
Manufacturing and production
The thing tracked is the production order, and the difference from trading is that stock transforms: raw materials go in and finished goods come out with a waste percentage.
The real workflow
An order or a production plan, then a production order for a quantity, then raw materials drawn against a bill of materials, then processing in stages, then finished goods and waste, then entry into stock, then delivery.
The screens that matter
Production orders with their stage. Then the bill of materials per product. Then actual unit cost against standard, which is what tells you whether your product is actually profitable.
The data model trap
The bill of materials needs dated versions. Changing a component today must not change the cost of production orders executed last year. A system holding one editable bill of materials quietly produces a wrong financial history.
What to build first
Production orders, the bill of materials and stock movements. Actual costing, scheduling and equipment maintenance come after.
Aviation and travel services
A sector I have worked in for three clients, and the shared lesson was a surprising one: what they needed was not a new system.
All three came asking for new websites with full rebuild budgets. What I found on inspecting what they had was that the underlying structure was sound, and the problem was presentation, speed and content rather than architecture. So they left with improved versions of their own sites for a fraction of what they had been quoted.
This is the section I would ask every reader to remember. Before you decide to build a new system, have someone competent inspect what you have and tell you whether the problem is in the structure, in how it is used, or in how it is presented. An inspection costs a small fraction of a build, and in many cases it ends with you spending ten percent to get eighty percent of the result.
When a system genuinely is needed in this sector, the thing tracked is the enquiry, and the value is in speed of response and organised follow-up, because a travel customer sends the same enquiry to three companies and books with whoever answers first with a clear number.
The integrations that matter in the Gulf
Any business system in this region talks to a small number of other systems, and getting each of those decisions right saves more than any feature.
Accounting
The first question: do you want one system that does everything, or two systems that talk? My answer in most cases is the second. Dedicated accounting systems do accounting better than any accounting module built inside an operational system, and your accountant knows them and does not want to learn another.
The right integration is narrow and specific: your operational system produces the entries or the invoices and sends them, and does not try to be the general ledger. Decide the direction of flow clearly at the start, because two-way synchronisation between two financial systems produces conflicts that nothing can resolve automatically.
Saudi e-invoicing
If your system issues invoices in Saudi Arabia this is not an optional integration. The invoice needs a prescribed structure, a QR code, and reporting to or clearance from ZATCA depending on your obligations. It touches the data model itself, so include it in the design rather than after it. Confirm your own obligations with your accountant or with ZATCA, then tell the developer what applies.
Payments
A regional gateway is the right default here rather than an international one, because Mada is the card most people in Saudi Arabia are carrying and Apple Pay converts on a phone better than anything else. Start merchant onboarding on the day the project starts; the paperwork and verification consume weeks and have nothing to do with whether the code is ready.
SMS and WhatsApp
SMS is reliable and expensive at volume. WhatsApp has far higher read rates in this region and needs a business account and templates approved in advance for messages you initiate. Template approval takes calendar time and belongs in the plan.
The practical rule: WhatsApp for reminders and updates the customer reads, SMS for verification codes, email for documents and invoices. Each channel costs, so send only what can be acted on.
HR and payroll
Usually requested as part of the system and usually the wrong decision. Payroll has statutory detail that changes, and dedicated systems follow it. Integrate only what you need: attendance, or project hours, or commissions, and send those to the payroll system.
Build or buy?
A question that deserves more time than it gets. This is a practical split by sector, drawn from what I actually recommend to clients.
| Sector | Usually | Why |
|---|---|---|
| Accounting and payroll | Buy | Statutory requirements change and a specialist follows them for you |
| Simple online stores | Buy | Salla, Zid and Shopify cover the normal case and launch weeks sooner |
| Property and development | Build | Reservation, payment and commission flows differ between every company |
| Clinics | Either | Good off-the-shelf clinic systems exist; build suits an unusual flow or several branches sharing resources |
| Construction | Build or hybrid | Bills of quantities and payment applications follow your contracts |
| Restaurants | Either | Buy the point of sale, build the owned ordering channel to save commission |
| Logistics | Build | Pricing, zones and cash-on-delivery settlement are specific to each company |
| Pilgrimage and umrah | Build | Package composition and network behaviour in season are not covered by general platforms |
| Training for individuals | Buy | Off-the-shelf learning platforms are sufficient and cheap |
| Corporate training | Build | The company as buyer, cohorts and HR reporting are missing from the ready-made options |
The rule that shortens the table: buy what is generic, build what differentiates you. If your objection to the ready-made platform is cosmetic or concerns one annoying step, live with it for a year. If the objection is that it prevents the way you work and make money, build.
There is a hybrid I use often and that gets overlooked: buy the base and build the layer specific to you on top through its API. A ready-made store with a custom system for contract pricing. A ready-made point of sale with a reporting layer built for you. This gives the better half of both and lowers cost and risk together.
How to get your team to actually use the system
Most of the systems I am handed to rescue were not technically broken; nobody was using them. That is not a programming problem but a rollout problem, and it is solvable.
Sit with whoever will use it before designing it
Watch the person do the job for an hour. Do not ask them how they work, because they will describe the official process. Watch, and you will find the note taped to the monitor, the step they always skip, and the case they handle with a phone call. Those are the requirements that never appear in a meeting.
Make the easiest path the correct one
If entering data in the system is slower than writing it in a notebook, the notebook wins. Reduce mandatory fields to what work cannot proceed without, and make everything else optional at first. You can make a field mandatory later once the system is a habit; you cannot persuade a team that rejected the system in its first week.
Load real data before day one
An empty system looks like a burden, and a system an employee opens to find their own customers and projects looks like a tool. Migrate what you can from spreadsheets before handover, even if it is incomplete, because eighty percent of the data is far better than a clean start.
Appoint an internal owner
One person in the business owns the system, gathers feedback, decides priorities and trains others. Without that person every observation becomes a direct ticket to the developer, requests conflict and improvement stops. Projects with that person behave completely differently from projects without one.
Stop the old method on a date
Running the system and the old method in parallel looks prudent and is the best-known cause of adoption failure. Having a fallback means nobody will learn the new way. Pick a date, run in parallel for two weeks to verify only, then actually close the old one.
The five numbers an owner should see
Most dashboards carry twenty figures and nothing gets read. These five I put in every system whatever the sector, and the rest on request.
- What came in and what went out this month, against last month and against the same month last year
- What is due and uncollected, oldest first, because that is the fastest cash available to you
- The work ahead, meaning confirmed orders, bookings or contracts not yet delivered
- What is late, meaning the count of items past their time, whatever the item is in your sector
- One sector-specific measure, such as no-show rate for a clinic, first-visit fix rate for maintenance, or reservation-to-sale conversion for property
Comparison is what makes a number useful. A figure alone says nothing; a figure next to last month says everything. Insist that every measure on your dashboard is compared against something.
Migrating your data out of spreadsheets
An item always estimated below its real size, and the one that delays projects more than anything else. The reason is that a spreadsheet permits what a database does not: a cell with two numbers in it, dates written three ways, a blank row in the middle, and a note typed into the price column.
What actually happens
The sheets are handed over, a program is written to read them, it rejects twenty percent of the rows for real reasons, and each rejection needs a human decision. Is this customer the same as that one spelled differently? What is the price when the cell says "250 or 300 depending on quantity"? What is the contract date when the cell says "start of the month"?
How to lower the cost
Clean the data before handover, which is work one of your staff can do at a lower cost than a developer's. Fix one date format, remove merged rows and headings inside the data, make every column hold one kind of value, and add a column with a unique identifier per record if there is not one.
And a decision that saves a great deal: do not migrate everything. Historical data that will not be used in live work can stay in an archived file. Move active customers, current contracts and present balances, and leave five years of archive where it is. It can be added later if you need it, and mostly you will not.
The line that belongs in the quote
Ask for migration as its own line with its own price, and for a trial run before final handover so you can see the result and fix the source. Migration performed once on launch day is a gamble for no reason, because you will discover the problems at the worst possible time.
Multiple branches and multiple companies
Two phrases that sound similar and mean two structurally different systems, and confusing them is one of the most expensive errors in this field.
Branches
One company with several locations. Data is shared and reports aggregate at company level, with branch as an attribute on the transaction. This is the simplest case and it needs specific decisions: are prices uniform or per branch? Is stock separate with transfers between locations, or shared? Does a branch manager see other branches? Answer all three before building, because each touches the data model.
Multiple companies
Independent entities, each with its own commercial registration, accounts and invoices, which may trade with each other. Here isolation becomes a strict requirement: one company's data does not appear in another's, and the owner's consolidated report is a separate thing built explicitly. This is noticeably more expensive than multiple branches.
Multi-tenancy
The third case, where you sell the same system to different customers from one deployment. This is not a feature to be added but an architecture decided in week one. Every query in the system carries the constraint that one tenant's data never appears in another's, and the constraint has to hold in search, reporting, exports and the mobile API, including on paths added a year later.
I built this in Omnixtrack and in Kassenta, and the lesson in both is that isolation is the project and the features are not. Getting it wrong once is not a bug but an incident a business does not recover from. So if you are thinking of selling your system later as a service, say so in the first meeting, because converting a single-company system to multi-tenant afterwards is work that approaches a rebuild.
When your team needs a mobile app
An app is requested in most projects and needed in few of them. My criterion is one question: does this person use the system while standing, moving, or away from a desk?
Drivers, technicians, warehouse staff and site supervisors need an app, because their hands are busy, their connection is poor and their screen is small. Their app has to do three things well rather than thirty: show what is assigned to them, record what they finished, and work when the connection drops.
Managers, accountants and reception staff do not need an app; they need a site that works properly on a phone. The difference in cost between those is large and the difference in value for these roles is close to nothing.
A third case where an app does earn its place: your end customer, if they use the service frequently, as in delivery or repeat booking. If they use it twice a year, a site is better, because nobody installs an app to use it twice.
Offline working is the item that must be explicit in the quote if it is required, because it is not a setting but a design: what is stored locally, how it is sent later, and what happens if what the driver sent conflicts with what the supervisor changed. That conflict decision is the real work, and skipping it produces an app that loses data quietly.
How to design permissions properly
A technical section in a buyer's language, because permissions are the thing most often implemented wrongly in systems built to a small budget, and the error does not show until it shows expensively.
Hiding a button is not a permission
The most important sentence in this section. The interface hides the button, but if the request the button sends still works when someone types the address directly, anyone with an account can perform the operation. A permission is enforced on the server on every request, and the interface hides things only to tidy the experience.
A test you can ask for: ask the developer to prove that a user on a limited role cannot reach a higher role's data even when the direct address is known. That is a fair request, and anyone who built it properly answers it in minutes.
Three levels, not one
Permission in business systems is three questions rather than one. Can this role see this screen? Can it see this particular record? Can it change this field on the record? Simple systems answer only the first, so they give an employee the right to see the customers screen and then they see customers from every branch.
The third level is always skipped: a salesperson may need to see the invoice without being able to edit the price on it. That is not a screen permission but a field permission, and it comes up constantly in sales and purchasing.
Start closed and open up
The correct design has deny as the default, with permissions opened explicitly. The reverse, allow by default with exceptions denied, means every new feature added a year later is open to everybody until somebody remembers to restrict it, which does not happen.
The system nobody uses
More than half of the systems I have been given to rescue worked technically and were not used. These are the reasons, in order of how often I find them.
Slower than the old way
Entering an order takes two minutes in the system and twenty seconds in a notebook. The logic is clear: the employee will pick the faster one, and they are right to. The fix is in the interface rather than in persuasion: fewer fields, remember the last choice, make search work on partial names, and add keyboard shortcuts for anyone entering data all day.
It does not handle the exceptions
The case the employee handles daily is not in the system, so they step outside it to get the job done, and two weeks later half the work happens outside the system and its data is wrong. The cause is that nobody asked about the exception during requirements.
It asks for data that does not exist yet
A mandatory field whose value the employee does not know at the moment they create the record. So they type anything to get past it. A month later you own a whole column that means nothing. The fix is to make the field optional at creation and mandatory at a later stage of the flow.
It gives nothing back to whoever enters the data
The employee enters and the manager benefits. That arrangement does not hold. Build something the person entering data benefits from directly: their task list, a search that saves them a phone call, a report on their own performance, or a form prefilled from what they entered before. The smallest direct benefit changes usage behaviour entirely.
Training once and then nothing
A training session on handover day is forgotten within a week. Better: a short session in the first week, then a second one two weeks later once the real questions have surfaced, with a short video per repeated task that a new employee can go back to. Ten three-minute recordings are more useful than a fifty-page manual nobody reads.
Why a system becomes slow after a year
A complaint I hear often from owners of systems built by someone else: it was fast at the start and now it is slow. The cause in ninety percent of cases is the same, and it is not the size of the server.
The real cause
The page asks the database for something inside a loop. A page with ten rows runs ten queries; a page with a thousand rows runs a thousand. In testing with little data it performs beautifully, and in year two with real data it collapses.
This is why upgrading the hosting usually does not fix slowness. A faster server runs the thousand queries slightly faster, and the problem is that the count should be one or two rather than a thousand. That is a fix in the code that takes hours for someone who knows what they are doing.
The second cause
Missing indexes on the columns being searched. A search without an index reads every record every time. That is also a quick fix with an immediate and noticeable effect.
The third cause
Reports calculated from scratch every time they are opened. An annual report aggregating a million records will always take its time. The answer is to calculate the aggregates periodically and store them, so opening the report becomes a read rather than a computation.
What to ask for
If your system is slow, do not ask for a bigger server first. Ask for a performance analysis that identifies the ten slowest pages and the cause of each. That is work measured in days rather than weeks, and every time I have done it the return beat any hosting upgrade.
And if you are building something new, ask for an explicit line in the quote: a performance test against a data volume resembling your size in two years, not your size on launch day. Cheap when requested in advance, expensive when discovered later.
Security in internal systems
Internal systems are assumed to need less security because their users are known. The opposite is truer in one important respect: the internal system holds all of your data, not a part of it.
The non-negotiable minimum
Encrypted connections, passwords stored so that a leak does not hand over accounts, permissions enforced on the server, immediate account disabling when someone leaves, and backups that have been test-restored. This is included in any competent build and should not be a line item.
What is worth adding in internal systems specifically
Two-factor authentication for administrative accounts. An audit log on financial operations, price changes and record deletions. Automatic sign-out after a period of inactivity, because office machines get left open. And restricted exporting, because the biggest risk to your data is not a breach but an employee exporting the whole customer list before they resign.
That last point gets skipped by everybody and deserves a decision: who can export, is the export logged, and is there a limit on record count. Logging exports alone changes behaviour.
A cheap habit
Never let real data sit on a developer's laptop or on an open staging environment. Anonymised copies for development cost almost nothing to produce and remove a whole category of risk that has nothing to do with code quality.
AI inside business systems
Requested in nearly every project now, and the honest answer is that most requests are better served by good search and a clear report. What genuinely pays for itself is narrow and specific, and these are the shapes I have seen work.
Ranking incoming enquiries
If you receive a high volume of enquiries and work them in chronological order, you are handling a small one before a large one. Scoring incoming enquiries by likelihood of converting and expected size changes the order your team works in, and it is among the cheapest additions with the highest return.
Extracting data from documents
If someone in your business retypes figures from supplier invoices, statements or contracts, this is a well-matched task. The only condition: the output is shown for review before saving rather than saved automatically.
Drafting a first version
A quote, a reply to a repeated enquiry, a summary of a matter or a project. The first draft is produced automatically and a person approves it. The order is not reversed: the machine proposes and the human approves.
This is what I built in Sigma PMO, where the analysis runs automatically across seventeen governance stages and nothing reaches a bank or an investor before a named person has approved it. The reverse arrangement, where outputs go out automatically, buys you a liability rather than a saving.
And the running cost
Model usage is an ongoing bill that grows with usage, unlike hosting. Ask for a monthly estimate against your real volume before approving any AI feature, because some ideas look good until their running cost is calculated.
What belongs in a quote for any system
A quote for a business system differs from one for a website, and these are the items I need to see before I treat a quote as serious.
- The list of roles and what each role can do
- The states of the tracked thing and its transitions, including moving backwards
- Integrations by name, and whether an API was verified to exist for each
- Data migration as its own line, after seeing your current data
- Permissions and the audit log explicit, not deferred to a second phase
- The reports included by name, and whether they export
- Whether there is a mobile app, for whom, and whether it works offline
- Training, documentation and short videos
- The defect warranty period after launch and the definition of a defect versus a new request
- Annual maintenance and what it covers
- Code ownership, and which accounts will be in your company's name
- Explicit exclusions
The two most important items are data migration and the exclusions. The first because it is the line most often priced below its real size and so turns into a dispute. The second because a supplier who writes down what they will not do has actually thought about your project.
Two projects costed from scratch
Theoretical splits only go so far. These are two cases where I work through the whole exercise: what the client asked for, what I recommend deferring, and the number either way.
A property developer with two projects and 150 units
The request as it arrived: a full system for sales, commissions and handover, a customer portal, a mobile app for the sales team, accounting integration, and an owner's dashboard.
| Component | Estimate | My view |
|---|---|---|
| Shared foundation: roles, permissions, audit log | $2,200 | Essential, not deferrable |
| Unit inventory and statuses | $1,800 | Essential |
| Reservations with a duration and automatic expiry | $1,400 | Essential, and it fixes an existing problem |
| Contracts, payment schedules and collection | $2,800 | Essential |
| Commission calculation | $1,600 | Phase two unless the dispute is live now |
| Handover with reports and photographs | $1,500 | Phase two, since the first handover is months away |
| Customer portal | $2,200 | Phase two, and its value is fewer calls rather than more sales |
| Mobile app for the sales team | $4,500 | Defer. The team is in a showroom at a screen; a site that works on a phone is enough |
| Accounting integration | $1,800 | Phase two, one direction only |
| Owner's dashboard | $1,200 | First version is five numbers and a weekly email, at $400 |
| Migration from the current spreadsheets | $1,100 | Essential, with a trial run before handover |
The full request is about $22,100. The first version I recommend, which is the foundation, inventory, reservations, contracts, migration and a reduced dashboard, is about $9,700 and ships in ten weeks instead of eighteen.
Price is the smaller reason for the split. The problem costing this client today is reservations nobody releases and payments that fall late with no alert. Both are solved in the first version. Commissions, handover and the app are problems they will face in months, and designing them after three months of using the system will be better than designing them today.
An air conditioning maintenance company with eight technicians
The request as it arrived: a system for work orders, technicians, inventory and maintenance contracts, with an app for technicians and an app for customers.
| Component | Estimate | My view |
|---|---|---|
| Shared foundation | $2,000 | Essential |
| Work orders and visits as two separate entities | $2,400 | Essential, and the separation is the heart of the system |
| Scheduling by skill and area | $2,200 | Essential |
| Technician app with checklist, photos and signature | $3,800 | Essential; this sector genuinely needs it |
| Offline working in the app | $1,400 | Essential, since technicians work in basements and on roofs |
| Inventory and spare parts | $2,100 | Phase two; a spreadsheet covers six months |
| Maintenance contracts and consumption | $1,900 | Phase two unless they are more than half the revenue |
| Invoicing and payment | $1,600 | Phase two |
| Customer app | $4,200 | I decline it. A customer requests service twice a year and will not install an app |
| Service request page with link tracking | $700 | The alternative to a customer app, serving the same purpose |
The full request is about $21,600. The first version, being the foundation, work orders, scheduling, the technician app with offline working and the request page, is about $12,500 over twelve weeks.
Note the difference between the two examples on the app line. In property I deferred the sales team's app; in maintenance I treated the technician app as essential and not deferrable. The criterion is the same in both: does this person use the system while moving, on a poor connection, with their hands busy? A showroom employee, no. A technician on a roof, yes.
In both examples I declined an item and recommended a cheaper alternative that serves the purpose. That is the question worth asking any supplier: which item would you suggest cutting from my request, and why? Anyone who answers is working in your interest.
Reports: what to ask for specifically
Reports are the item written into quotes in one line and then delivered in a form nobody uses. This is the way I recommend asking for them.
Ask for the report as a question, not a name
"Sales report" means nothing. "Which branch had the highest margin this quarter?" is a question, and it tells the developer what has to be recorded in every transaction for the answer to be possible. Write five to ten questions in that form and you will have written the whole reporting specification.
Always ask for export
Every report exportable to a file. The accountant will ask for a file, the investor will ask for a file, and the manager will want to analyse it in a spreadsheet their own way. A handsome on-screen report without export means somebody will retype it, which is exactly what you built the system to avoid.
Ask for comparison in every number
Every measure against the previous period and against the same period last year. A single figure does not get read; a compared figure gets acted on. It is a small addition in the build and a large one in use.
Ask for a report that arrives without opening the system
A daily or weekly summary by email or WhatsApp to the owner and managers. This will be the most-read report in the whole system, because it requires opening nothing. In my experience adding it changes the owner's relationship with the system more than any dashboard does.
Resist the large dashboard
A board with twenty measures gets opened twice and then forgotten. Five numbers with their comparisons, and a button to open the detail when needed, is far more useful and cheaper to build.
Should you pick a supplier who knows your sector?
A question worth a detailed answer, because the obvious answer is not always right.
A supplier who has built ten systems in your sector knows the exceptions in advance, and that is real value which saves weeks of discovery. They will ask about cases you had not considered because they saw them elsewhere, and warn you off decisions others regretted.
The other side: they may build you what they built for the others, assuming your business is like theirs. And your business has something that sets it apart or you would not still be trading. So if you find a supplier experienced in your sector, test them with one question: what is different about my case from the one you know? Anyone who answers in detail listened; anyone who says all cases are alike will sell you somebody else's system.
And a supplier who does not know your sector is not necessarily a worse choice, provided they ask a lot and sit with your team and watch them work. In my experience the quality of the questions is a more accurate signal than the number of projects in the same sector.
The order I would recommend: choose on competence and communication first, sector experience second. A competent supplier learns your sector in two weeks; a supplier who knows your sector but builds poorly hands you a system that understands your business and does not work.
What happens when your business doubles
The question to ask before building rather than after, because its answer determines decisions that cannot easily be changed.
What grows easily
Record and user counts in a properly built system grow to many multiples without trouble. And adding a branch, a service type or a pricing plan, if the model expresses your business, is data entry rather than a code change.
What does not grow
Three things need an early architectural decision, and their cost after two years approaches a rebuild. First, entity isolation if you decide to turn your system into a service you sell to others. Second, record-level permissions if you will need each user to see only part of the data. Third, multiple currencies and legal entities if you will expand to another country.
So if any of the three is a plausible item in your three-year plan, say it in the first meeting. The cost of building the foundation correctly at the start is small; the cost of adding it later is very large.
The signal that a system was not built to grow
If every simple change needs a developer, the system was not built to grow whatever you were told. The test I give clients: ask for a new service at a new price, add a user with different permissions, and open a branch. If any of the three needs code, you own a system that describes your situation rather than one that runs your business.
Ten questions to ask yourself before any system
This list condenses the whole article, and your answers to it are half the project.
- What is the one thing the system will track?
- What are its states, who owns each transition, and what happens going backwards?
- Who uses it, and what must each role not be able to do?
- What are your three hardest cases, and do they pass through the system or around it?
- Which questions do you want answered at month end, and is the data for that being recorded?
- Which systems must it talk to, and do they actually have APIs?
- Who will own it internally, and are they available?
- What is the smallest version you could run your business on?
- Do I need a mobile app for anybody, or just a site that works on a phone?
- Am I planning to sell this system to others, or expand to a second country, within three years?
The eighth is the most important and the most neglected. The smallest workable version is not a reduced version but the correct strategy, because it starts returning before the project is complete and it gives you three months of evidence before you decide on phase two.
How to measure whether the system worked
Most companies do not measure, so they judge the system on a feeling: are people complaining or not. That is a poor measure, because the complaints come from the change rather than from the system. These four you can read accurately after three months.
The share of work passing through the system
The most important measure and the most ignored. Take the number of transactions recorded in the system this month and divide by the real number you know from your accounts. If it is below eighty percent, part of your business is happening outside the system, your data is wrong, and every report built on it misleads.
A low share is not a compliance problem but a signal that the system does not handle a real case. Ask where the missing transactions are recorded and why, and you will find the exception nobody asked about at the start.
The hours freed
Measure the same thing you measured before building: how many hours a week the replaced process consumed. If you did not measure it before building you will not be able to prove anything, which is why I ask for the measurement before the start rather than after.
How often a number is requested by email
An indirect and very honest measure. If the owner is still asking staff for figures by email or WhatsApp, the reports failed; if they open the system or read the weekly summary, the reports worked.
The mistakes that stopped
Before building, write down the mistakes that cost you money and recur: the double booking, the enquiry nobody follows, the invoice that gets forgotten, the statutory deadline that passes. After three months, count them. This is the clearest evidence of return and the easiest to convert into money.
And what to do with the result
The four measures define phase two more accurately than any plan. If the share of work inside the system is low, phase two is covering the exceptions rather than adding features. If it is high and hours were freed, phase two is the next process that consumes time. If the owner is still asking by email, phase two is reports and nothing else.
That is the difference between a business that builds a system once and lets it rot, and a business whose system becomes an asset that grows with it. The first decides phase two on a feeling; the second decides it from four numbers gathered in an hour.
Cost and timeline by system type
Practical figures in US dollars from projects I have delivered, assuming a clear brief and a single decision maker. They are for a first workable version rather than a complete system with every phase.
| System | First version | Timeline | What raises the number |
|---|---|---|---|
| CRM and enquiry management | $4,000 to $12,000 | 6 to 12 weeks | Multi-tenancy, accounting integration |
| Booking and appointments | $4,000 to $20,000 | 5 to 12 weeks | Multiple resources, payment, several branches |
| Inventory and retail | $6,000 to $25,000 | 8 to 16 weeks | Branches, variants, linking sales channels |
| Property and unit inventory | $8,000 to $30,000 | 8 to 18 weeks | Commissions, handover, customer portal |
| Construction and payment applications | $10,000 to $35,000 | 10 to 20 weeks | Actual costing, subcontractors |
| Logistics and delivery | $10,000 to $40,000 | 10 to 20 weeks | Driver app, cash on delivery, live tracking |
| Legal matter management | $5,000 to $18,000 | 6 to 14 weeks | Hourly billing, record-level permissions |
| Corporate training | $6,000 to $30,000 | 8 to 18 weeks | The company layer, assessment, certificates |
| Field service and maintenance | $7,000 to $25,000 | 8 to 16 weeks | Technician app, inventory, maintenance contracts |
Three notes on every row. A mobile app for a field team is not a small item and typically adds 30 to 50 percent. Migration from your current data is an independent line estimated after seeing the sheets. And annual maintenance runs 10 to 20 percent of build cost, higher for systems with many integrations.
How to write your requirements in two pages
This document is the cheapest thing you can do and the one with the largest effect on what you get. Here is the structure exactly, so you can write it yourself before speaking to any developer.
Page one
Two lines on the problem, phrased as what happens today and what it costs. Then one sentence naming the thing the system will track. Then the list of roles, each with three to five things it does and one thing it must not do. Then the list of states of the tracked thing in order, who owns each transition, and what happens going backwards.
Page two
The systems it has to talk to by name, whether they have an API, and whether you have credentials. Then the numbers you want at month end, written as questions. Then your real size: how many users, how many transactions a month, how many branches. Then the constraints: budget range, the date required and why, and who approves.
An optional appendix that changes the quote
A third page with your three hardest cases written as stories. "A customer reserved a unit, paid half, then asked to transfer the reservation to his brother" is more useful to a developer than twenty lines of specification. It is also the fastest way to find out who understood your problem and who did not.
A ninety day plan from zero
If you decide to start, this is the order I recommend, built around the return beginning before the system is complete.
Weeks one and two
Write the two-page document. Sit with whoever will use the system and watch them work. Clean your current spreadsheets. Start anything external that takes time, such as a payment gateway or a WhatsApp business account, because those consume weeks and have nothing to do with programming.
Weeks three to six
Choose the supplier and agree a written scope with exclusions. Build the shared foundation and the single flow that consumes the most hours in your business. By the end of this period you should have something you can open and enter real data into, even if it is incomplete.
Weeks seven to ten
Finish the first flow, add the five core reports, run a trial migration and review the result and fix the source. And train an internal person to be the system's owner.
Weeks eleven to thirteen
Run in parallel for two weeks to verify only, then stop the old method on a fixed date. And hold two weeks of developer time for the month after launch, which is the highest return in the whole project.
Beyond ninety days: watch where staff go back to the old way, because that signal tells you what the system is missing more precisely than any roadmap you wrote at the start. Phase two designed on three months of real use is a far better project than one planned on day one.
Three mistakes that cost more than any technical decision
Building everything at once
A system launched complete after nine months carries nine months of untested assumptions. A system launched incomplete after two months starts correcting itself immediately. Choose the second always, and not because it is cheaper but because it ends in a better system.
Copying a competitor's system
A request I get often: build me one like theirs. The problem is that theirs is built on their process, with decisions you cannot see from the outside and that do not suit you. Copy what you understand the reason for, and ask about the rest.
Deferring permissions and the audit log to phase two
The worst possible deferral. Roles, permissions and a record of who did what are structure rather than features, and adding them after a year of operation is work approaching a rebuild. A report or a screen is easy to add at any time. So if you have to cut, cut features rather than structure.
Where to start
If you are in one of the sectors above and thinking about a system, the shortest route to a number and a plan is this: write the two-page document, add your three hardest cases, and send it with your real size and your budget range.
I will reply with an estimate, with what I think the correct first version is, and with what I recommend deferring. In the cases where the answer is that you should buy a platform rather than hire me, I say so, because a system you did not need is worse for me than it is for you.
And if you already have a system and are thinking of replacing it, start with an inspection before any decision. An inspection establishes whether the problem is in the structure, in how the system is used, or in its performance, and it costs a small fraction of a rebuild. In many cases it ends with you spending ten percent to get eighty percent of the result you were about to buy with a full rebuild. I did this for three aviation clients and all three left with improved systems rather than new ones.