Service

Custom Web Applications

For businesses whose day-to-day operation has outgrown spreadsheets and generic tools, and who need software shaped around the way their work actually flows, from the first request to the last invoice.

The problem

What goes wrong today

Where it usually starts

The business that asks for a custom application has usually tried the alternatives.

  • It runs on a collection of spreadsheets, a shared calendar, an off-the-shelf tool chosen for one department and a lot of memory in the heads of two or three people.
  • The job that comes in by phone is written on a pad, typed into a spreadsheet by someone else and copied into an invoice by a third person a week later; each step loses something.
  • Stock is counted when it runs out.
  • The off-the-shelf tool handles sixty per cent of the process well and the remaining forty per cent is done around it, with exports, re-keying and a column called "notes" that holds the real information.

Where it gets harder

Reporting is a monthly exercise of pulling three files together, and the answer to "how many jobs are waiting on a part" is a walk to the workshop.

  • New staff take months to learn where everything is.
  • The owner knows the software they want does not exist as a package, because every demonstration they sit through assumes a workflow that is not theirs.
  • What they need is a system built around their own stages, their own vocabulary and their own exceptions, with the awkward cases designed in rather than worked around.

Scope of the service

What the build covers

A custom web application build normally covers one operation end to end. We begin by walking through the real work: how a request arrives, who touches it, what decisions are made at each step, what documents and numbers are produced and where it ends. Each step becomes a named stage with its own screen, rules and permissions. The build typically draws on a set of capability modules we maintain and configure rather than rewrite: records and cases, diaries and resource capacity, stock per location, documents and templates, forms and requests, messaging and notifications, and quotes and invoices through the payment layer. The sector-specific part is the configuration, the vocabulary, the screens and the rules, not forked code.

The application runs in the browser on desktop and phone, with roles for each kind of user, an audit trail of who changed what, reports built from the real data, and exports so your data is never locked in. Existing spreadsheets and system exports are migrated with their history.

When the scope grows

Scoping scenario

An independent vehicle inspection business with three bays wants job cards that move from booking through inspection, parts waiting, re-test and sign-off, with photographs attached at each step, a diary that knows which bay and which inspector is free, and an invoice generated from the completed card. No package covers the bay pairing and the re-test loop; the scope document names each stage and the rules that move a job between them.

Deliberately out of scope

  • Replacing your accounting system, which we connect to
  • Hardware such as scanners and printers beyond confirming they work with the application
  • Processes that stay on paper by choice, which we record as excluded so the system does not pretend to hold them

Deliverables

What you receive

  • Discovery notes from walking through the operation with the people who do it, including the exceptions
  • A written scope document naming each stage, role, screen and rule, and what is deliberately left out
  • Designs of the main working screens on desktop and phone, including the stage board or diary at the heart of the system
  • The build, deployed to your hosting or ours, with roles, audit trail and reports in place
  • Migration of your spreadsheets and system exports with history preserved
  • Training for each role with a short written guide, and a test period alongside the current process
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Copies of the spreadsheets, forms and exports in use today; a visit or call with each person who handles a job.

    Project stage: Onboarding
  2. Planning

    The operation is mapped stage by stage with its exceptions; stages, roles, rules and reports are written into the scope document.

    Project stage: Planning
  3. Design

    The central working screen first, then each role's screens, designed for the device each role actually uses.

    Project stage: Design
  4. Development

    Records and stages first, then diaries, stock or documents as scoped, then reports, exports and integrations.

    Project stage: Development
  5. Client review

    Your team runs a week of real jobs through the system alongside the current process and tells us where it does not match.

    Project stage: Client review
  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions
  7. Ready for launch

    Data migrated and reconciled against the spreadsheets, users and roles set up, the cut-over day agreed.

    Project stage: Ready for launch
  8. Delivered

    The team works in the system; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Accounting software for invoices, payments and customer records
  • Payment providers for deposits and balances through the provider-independent payment layer
  • Email and SMS providers for customer and staff notifications
  • Calendar systems for staff diaries and resource availability
  • Document storage and e-signature services
  • Supplier and parts ordering systems where they publish an interface
  • Label printers, scanners and barcode workflows through the browser

How we would approach it

Worked example

Concept demo

A vehicle inspection business with three bays and a re-test loop

The situation

An inspection business wants every job on a card that moves from booking to inspection, to waiting for parts, to re-test and to sign-off, with photographs at each step, a diary that pairs a free bay with a free inspector, and an invoice produced from the completed card.

Why it is a custom build

The custom route is needed because the bay pairing, the re-test loop and the stage rules are specific to this operation and no package models them without workarounds.

The scope we would propose

  • A job record with named stages and the rules for moving between them
  • A diary with bay and inspector capacity, photograph capture from a phone attached to the stage it was taken at
  • A parts-waiting list visible to the front desk
  • A re-test loop that returns the card to inspection without losing history, invoice generation through the payment layer and a daily report of jobs by stage

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of stages in the operation and how many exceptions and loops it has
  • Roles and the differences between what each can see and do
  • Capability modules involved: diaries, stock, documents, messaging, quotes and invoices
  • Reports and exports required, and whether any must match an existing format
  • Volume and condition of spreadsheets and exports to migrate
  • Systems to connect, especially accounting and supplier interfaces
  • Phone and offline use by field or workshop staff
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

How do you decide between a package and a custom build?

We map your operation first. If a package such as the workshop management package, the law firm management package or the warehouse management package covers your stages with configuration, we propose it. If the stages, pairing rules or exceptions need to be designed in, we propose a custom build and say why in the scope document.

Is a custom application built from nothing?

No. It is assembled from capability modules we maintain, such as records and stages, diaries and capacity, stock, documents, forms and messaging, with the screens, vocabulary and rules designed for your operation. That keeps the build focused on what is specific to you.

Can our existing spreadsheets be imported?

Yes. Spreadsheets and exports from current tools are mapped to the new records and imported with their history, then reconciled with you before cut-over. Where the data is inconsistent, we agree the cleaning rules with you rather than guessing.

Will staff be able to use it on a phone or in the workshop?

Each role's screens are designed for the device that role uses. Workshop and field screens are designed phone-first, with large targets and photograph capture; office screens make use of the larger display. Offline use is scoped where a site has no reliable connection.

Who owns the system and what if we want to change it later?

You own the source code and your data. Changes after delivery are quoted as change requests against the scope document, or handled within a maintenance agreement, and the audit trail and exports mean you are never locked in.

Get a project quote for custom web applications software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote