Skip to main content

Business process analysis before development

Every project starts by looking at how the work runs today. The first analysis and an initial product plan are free: you receive a diagram of your process, a plan for the software and, where agreed, a prototype.

Discuss your projectBook a 15-minute call (opens in a new tab)

How a project runs

Four stages, from analysis to handover

Every project follows the same four stages, and each one ends with something in your hands.

  1. Analysis

    We review your process and requirements

    A conversation about the software and what it has to do, then a review of how the work runs today. If you have a brief or a specification, we review it too.

    What happens

    • who enters which data, and where
    • which data is entered more than once
    • the steps handled outside any system
    • where work stalls or depends on one person

    What you get

    • A diagram of your current process
    • The problem areas identified in it
    • An initial plan for the software
    • A prototype, if one was agreed

  2. Design

    We design the solution around your company

    The solution follows your company’s structure, requirements and way of working. The scope, schedule and price are set from the findings of the analysis and agreed before development begins.

    What happens

    • tools that already work are connected, not replaced
    • what the first version must include, and what can follow
    • which system remains the source of record for each item of data

    What you get

    • The solution, documented before it is built
    • An agreed scope, schedule and price

  3. Build

    We build and test it

    We build the software the analysis defined. As a guide, a first prototype takes about a week, and production about a month.

    What happens

    • a first prototype to review, then the production system
    • the system passes tests before each release
    • development can be paid for in stages

    What you get

    • A first prototype
    • The working system, tested before release

  4. Handover

    We hand it over in full

    At delivery, the source code is handed over in full and the repository and infrastructure accounts are transferred to you, so nothing remains outside your control.

    What happens

    • the access your team granted for the project is revoked
    • support is a separate service, agreed per project
    • change requests are taken on without a support agreement

    What you get

    • The working system and its source code
    • The repository and infrastructure accounts
    • A short guide for the people who operate it, and a handover call

Writing a brief

How to write a software requirements brief

A brief says what the software is for before anyone designs it. These eight points cover what we need to know; each can be a few sentences.

No formal specification is needed. Describe it in your own words, and the analysis and design turn it into a documented plan.

  1. The goal and the problem

    What is going wrong or missing today, in business terms, and why it matters now: lost time, errors, delays, work that depends on one person.

  2. Who uses it, and in which role

    Every group that will work with the system — sales, operations, finance, management, your customers — and what each of them needs to do or see.

  3. The current process, step by step

    How the work runs today, from the first request to the finished result, including the steps that happen in email, chats or on paper.

  4. The tools and data involved

    The systems, spreadsheets and services in use now, what data each one holds, and roughly how much of it there is.

  5. What must change

    How you will know it works: which steps disappear, what is entered once, and what anyone can see without asking a colleague.

  6. Must-haves and nice-to-haves

    What the first version cannot go live without, and what can follow later. Separating the two keeps the first version focused.

  7. Constraints

    Deadlines and the reasons for them, a budget range if you have one, and the systems that must stay in place.

  8. Access and sensitive data

    Which systems the work would need access to, whether a copy or a test account would be enough, and whether the data is personal, financial or otherwise sensitive — including whether you need an NDA.

What helps

  • Describe what happens today, not only the feature you have in mind.
  • Attach real examples: a typical order, a report, a screenshot of the spreadsheet, with sensitive data removed.
  • Name who makes the decision and who will use the system every day.
  • Say which requirements are fixed and which are open to discussion.

What to avoid

  • Designing screens and buttons before the process is clear.
  • Listing every feature at the same priority.
  • Leaving out the workarounds, such as the side spreadsheet or the chat where approvals happen. They often show where the problem is.
  • Waiting for a complete document. A first version in your own words is enough to start.

Example

An example brief

An illustrative example for a fictional wholesale distributor, written to the eight points above. Use it as a pattern: plain language, real detail, and nothing that needs a technical background.

Download the template

The same eight points, with a hint under each. Fill it in, or use it as a checklist for an email; either is enough to start.

Word document12 kBPlain text (Markdown)3 kB

Illustrative example · fictional company

Order handling for a wholesale distributor

The goal and the problem

We distribute packaging materials to about 60 regular business customers. Orders arrive by email and phone and are typed into a shared spreadsheet, then re-entered into our invoicing service and copied into a picking list for the warehouse. Quantities and addresses are sometimes wrong by the time an order ships, and nobody can tell an order’s status without asking the warehouse.

Who uses it, and in which role

  • Sales coordinators (2): enter and confirm orders.
  • Warehouse staff (4): pick, pack and mark orders as shipped.
  • Accountant (1): invoices and payment status.
  • Managing director: a weekly view of orders, shipments and overdue invoices.
  • Customers: today they email to ask about an order; we would like them to see its status.

The current process, step by step

  1. A customer emails an order, as free text or as their own PDF.
  2. A coordinator types it into the orders spreadsheet and checks stock in a second one.
  3. The coordinator emails a picking list to the warehouse.
  4. The warehouse ships the order and replies by email.
  5. The accountant creates the invoice in the invoicing service, from the spreadsheet.
  6. Payments are tracked in a third spreadsheet.

The tools and data involved

  • Google Sheets: orders, stock and payments, about 4,000 order rows a year.
  • A cloud invoicing service, which the accountant’s reports depend on.
  • A shared email inbox for orders.
  • The courier’s website, where shipping labels are created by hand.

What must change

  • An order is entered once and reaches the warehouse and invoicing without re-typing.
  • Anyone on the team can see an order’s status without asking.
  • Stock updates when an order ships.
  • The managing director sees orders, shipments and overdue invoices on one screen.

Must-haves and nice-to-haves

  • Must have: order entry, the stock check, the picking list, shipped status, and an invoice created from the order.
  • Nice to have: order status for customers, orders read from email, courier labels.

Constraints

  • Keep the invoicing service; the accountant’s reporting depends on it.
  • The first version should be in use before our busy season, in about four months.
  • We have a budget range for this year and can share it on a call.

Access and sensitive data

  • Customer names, addresses and prices are commercially sensitive; we would like an NDA.
  • We can grant access to copies of the spreadsheets and a test account in the invoicing service.

Attached: two sample orders and the current spreadsheets, with customer details removed.

What to send us

A brief in your own words, or a few paragraphs through the form below. Sample documents and screenshots help, with sensitive data removed.

What it costs

The first analysis and an initial product plan are free. The price of development is set after the analysis, from its scope, complexity and urgency, and agreed before work begins. Payment can be made in stages; the price can change if the requirements change or the scope proves larger than described.

How long it takes

The schedule is set from the findings of the analysis. As a guide, a first prototype takes about a week, and production about a month.

How to start

  1. Describe the task

    Tell us about the problem and the process around it, in your own words. No specification is needed.

  2. First analysis and an initial plan

    We review your process and requirements at no charge. You receive a diagram of the process and an initial plan for the software.

  3. A price for your project

    The price is set after the analysis and agreed before development begins. It may change if the requirements change or the scope grows, and can be paid in stages.

Discuss your projectBook a 15-minute call (opens in a new tab)

Get in touch

Tell us about the problem you want to solve

We will reply, ask about your current process and propose where to start. If this page has not answered your question, ask it here.

We reply within 24 to 48 hours, in the order requests arrive.

Or write to us at hello@healed-code.com

Budgetoptional
Choose a rangeNot sure yetUnder $1,000$1,000 to $5,000$5,000 to $15,000Over $15,000
Budget
Timelineoptional
Choose a timelineAs soon as possibleWithin a monthOne to three monthsExploring options
Timeline

Book a 15-minute call (opens in a new tab)

By sending this you agree to our privacy notice and terms of use.