01
Line-of-business applications
The system your operation runs on, shaped around your actual process rather than a vendor's idea of it.
Build
Software your team stops working around.
When a spreadsheet grows a second sheet of workarounds, it has stopped being a spreadsheet and started being an application with no safety rails. A proper web app puts the rules in one place, keeps a history, and lets more than one person work at once.
Why it matters
The short version.
There is a recognisable moment when a business outgrows its tools. Someone maintains a spreadsheet that other people depend on. A process has a step that only works because a particular person remembers to do it. Two systems hold the same information and disagree. None of these are crises, which is exactly why they persist for years.
Custom software earns its cost in one of two situations: when your process is genuinely a competitive advantage and shaping it to fit a product would throw that away, or when nothing on the market fits without so much contortion that the workarounds become their own system. Outside those two, buying is usually the better answer and we will tell you so.
The largest risk in a build is not technical, it is scope. Software projects rarely fail because something could not be built; they fail because the thing being built kept growing. We manage that with fixed phases, working software every two weeks, and a willingness to argue about whether a feature earns its place.
Projects rarely fail because something could not be built. They fail because it kept growing.
Is this you?
You probably need this if…
- A critical process runs on a spreadsheet only one person understands
- Staff re-key the same information into two different systems
- You cannot answer a basic question without someone compiling a report
- Your current tool nearly fits, and the gap is costing hours every week
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Dashboards and reporting
Numbers everyone trusts because the definitions are written down and applied consistently.
03
Customer and client portals
Self-serve access that reduces inbound calls rather than creating a new inbox.
04
Integration
Connecting the systems you already pay for, so information stops being re-typed.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Rebuilding the spreadsheet exactly
The spreadsheet has years of accumulated workarounds for limitations the new system will not have. Copying it faithfully copies the compromises too.
-
Launching to everyone at once
A staged rollout lets you find the problem with ten users instead of four hundred. The instinct to flip the switch for everyone is understandable and usually wrong.
-
Skipping the boring parts
Permissions, audit trails and error handling are unglamorous and are the difference between software you can rely on and software you have to supervise.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Map the process
Including the undocumented parts, which is most of the value of this phase.
-
02
Prototype
A clickable version tested with the people who will use it daily.
-
03
Build in sprints
Two-week cycles, a staging deploy every Friday, no reveal day.
-
04
Migrate and launch
Data migration rehearsed twice before it is real, then training.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
A working application, tested on real devices
Source code in your repository
Automated tests around the parts that matter
Documentation and a recorded handover
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Usually a mainstream, boring stack — the kind any competent developer can pick up. We optimise for you being able to hire someone later, not for our own novelty.
Often yes. We start with a paid audit, usually a week, and give you an honest read on whether to stabilise or replace. Sometimes the answer is to keep it and hire a contractor, and we will say so.
In Canada by default, on infrastructure in your name. That matters for privacy legislation and for procurement teams who will ask.
That is normal and the process expects it. Because we work in two-week cycles with working software at the end of each, changing priorities costs you the current cycle rather than the whole plan. What we will do is be explicit about the trade — what moves out if this moves in.
You do. Cloud accounts are created in your name with us given access, not the other way round. If we part ways, you change a password rather than start a migration.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.