Custom Business Software
Workflow applications: the rules of the process live in the app
A process that lives in one person's head
Every permit packet looks alike until it reaches the building department. Eastside wants a load calculation and a site plan; Riverside doesn't; Northside changed its form in the spring. The coordinator knows all of it. When they're away, packets go in incomplete and come back weeks later.
A workflow application holds those rules. A new job in Eastside gets Eastside's list. Each item goes to the person who supplies it. The packet can't be submitted until the list is complete, and a correction from the town reopens exactly the step it concerns.
Today, and with a workflow application
Today
- 01The coordinator starts a packet from last time's folder.
- 02Requirements are remembered, or looked up on the town's site.
- 03Documents are chased by text and email.
- 04Corrections arrive by email and wait in someone's inbox.
Incomplete packets go in, come back weeks later, and the job's start date slips.
With a workflow application
- 01A job that needs a permit opens a packet with its town's list.
- 02Each item is assigned to the person who supplies it.
- 03The packet can't be submitted until every item is attached.
- 04A correction reopens the step it concerns and notifies its owner.
Every packet complete the first time it goes in, whoever prepares it.
Six states, and what moves a case
The rules, town by town
Northside
- Required
- application form, equipment spec sheet, contractor licence copy
- Fee
- paid online at submission
- Inspection
- booked by phone after approval
- Kept current by
- coordinator
Eastside
- Required
- application form, equipment spec sheet, load calculation, site plan
- Fee
- paid at submission
- Inspection
- booked through the town's portal
- Kept current by
- coordinator
Riverside
- Required
- application form, equipment spec sheet
- Fee
- invoiced after approval
- Inspection
- booked online after approval
- Kept current by
- coordinator
The parts it's built from
What changes from one business to the next
A common starting point is a Postgres database holding cases and rules, a Next.js application, n8n for reminders and status checks, and connections to the system that holds your jobs. These are starting candidates, not requirements.
Is a workflow application the right system?
Good fit
- A process has several steps, several people and rules that vary by case.
- Mistakes send work back weeks.
- The rules can be written down, even if only one person knows them today.
Avoid when
- Several processes need to share one queue and one set of records. Look at a workflow platform.
- The process is one approval. Look at approval workflows.
How we'd approach it
01
Understand
As much as the problem needs
We map how the work runs today: who does what, which systems hold the records, and where it breaks.
02
Design
Decided before it's built
Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.
03
Build
Connected to what you use
We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.
Questions about workflow applications
Couldn't we use a project management tool?
For tracking tasks, yes. It won't know that Eastside needs a site plan, or stop a packet going in without one.
What happens when a rule changes?
Someone with permission edits the rule. New cases use it straight away; cases already under way keep the rules they started with unless you choose otherwise.
Can the town's status come in automatically?
Where the town offers a portal or an API, yes. Otherwise a person records it, and the next step starts from there.
What about cases that don't fit?
A person can override a rule, with a reason. The override is recorded, and frequent overrides tell you a rule needs changing.
Get the process out of one person's head
Tell us about the process that depends on one coordinator. We'll show you how each case would move.