Custom business software and ERP development, built around how your team already works

1. 01

   Walk the work, not the org chart

   We sit with the people who do the work and follow one real job from the first enquiry to the final bill: who touches it, what they type, what they print, what they wait for and where it stalls. For a fire-protection contractor that meant tracing a project through design and costing, the client's purchase order, buying, deliveries to stores and site, installation and a joint measurement before billing. The output is an operational flow and a storyboard you can check line by line.

   The usual mistake: Skipping this and starting from a feature list. The list says "inventory module"; the walk-through finds that stock is received at the gate, held in stores and measured again on site, three different numbers a system must keep apart.

   You see: An operational flow of your business, on one page

2. 02

   Name every role and what it may see

   Each person gets a role, and each role gets a precise list of what it can see, change and approve. This is where commercial rules live: management sees margin, procurement and stores never do; sales releases a work order only after the engineer, the in-charge and the managing director have each approved the quotation. Writing this down early is what stops a system from leaking numbers later.

   The usual mistake: Leaving permissions to the end, when the screens already show everything to everyone and hiding a number means rebuilding the screen.

   You see: A roles and permissions table you sign off

3. 03

   Model the data the way the business thinks

   The data model decides whether a system fits or fights you. A fabricated product is not a price-list item, so we modelled one client's products as spec sheets made of reusable parts, with cost falling out of the parts. A project line that is bought from two vendors, arrives short and measures longer on site needs quantities derived from recorded events, never typed in. Money is stored in whole paise, so totals never drift.

   The usual mistake: Treating every product as a priced SKU and stock as one average rate. It looks simple, and it gets costing, buying and margins wrong for any business that makes things or buys the same part at different prices.

   You see: A data model explained in your words, not ours

4. 04

   Specify every screen with a stable ID

   Before anything is drawn, every screen is written down: layout, fields, states and who can open it, each with an ID such as FN-03 for the third finance screen. The same ID follows the screen into design, code and tests, so a question about "the stores receipt screen" has one answer. For an aviation academy that was 135 screens across 17 roles, specified before a single board was designed.

   The usual mistake: Designing screens before they are specified. The boards look finished, and nobody notices the missing empty state, the error message or the screen the auditor needs until the code is written.

   You see: A screen-by-screen specification

5. 05

   Let each team click through its own day

   We turn the specification into a clickable prototype with one entry per role, running in a browser on sample data. The stores keeper clicks through a goods receipt; the managing director approves a quotation. People find what is missing far faster by doing their job than by reading a document. One client asked for four additions after its walk-through, and all four went in before any of that workflow was built for real.

   The usual mistake: Showing the prototype only to the owner. The person who receives goods at the gate knows things the managing director does not, and they are the ones who will use the screen every day.

   You see: A prototype for every role, before code

6. 06

   Build in slices that each work end to end

   The real system is built one role-complete slice at a time, data before the screens that read it: sign-in and team, then masters, then the first full workflow. Each slice ships with its own tests, API checks and scripted browser click-throughs, and is shown to you working before the next begins. You never wait months to see whether the system is right.

   The usual mistake: Building every module halfway at once. Ten half-finished modules are worth nothing to a team; one finished workflow is worth using on Monday.

   You see: Working software every few weeks

The first five steps are where most of the thinking happens, and they are also the cheapest to change. A misunderstanding found on a whiteboard costs a conversation; found in a prototype it costs an afternoon; found in production it costs weeks and the team's trust in the system. That is why we would rather spend an extra week walking the work than an extra month rebuilding a module nobody uses.