Home · Services · Applications & solutions
Service · Applications & solutionsYou already know what should exist. This is where it does.
The screens your people and your customers actually open — a web application, a mobile app, the internal tool that replaces the whiteboard and the group chat. Specified, designed, built, launched and connected to the systems you already run. One person writes the specification and then has to build it, so the specification cannot quietly promise what the build will not deliver.
Software we buildA running application in your own accounts, with the source code in your name as it is written
Bring the thing you keep describing in meetings. Half an hour with the people who would build it, with no obligation and nothing pitched. You'll leave with the smallest version of it that would be genuinely useful — and if something that already exists does the job, you'll hear its name instead.
A written spec, then software you can open at every stage.
Two things decide whether custom software delivers what it should: whether everyone agreed what "done" meant, and whether anyone outside the build saw it before the end. So the spec comes before the code, and there is something you can click at every stage after it.
A finished product, and the keys to it.
Four outcomes a build is scoped to produce, and then the artefacts that outlive it. Nothing here is licensed back to you — the accounts are opened in your name at the start, not signed across at the end.
Software your customers can open and your team can run on an ordinary Tuesday. Not a demo, not a slide, not a pilot that quietly never shipped.
An off-the-shelf tool fits the general shape of the job and not your specific one, which is why people fight it daily and keep a spreadsheet on the side. This is built around how the work already moves.
Source code, accounts and keys in your name from the start. There is no FuseLoom platform underneath it — nothing to licence, nothing to renew, nothing held over you.
Training for the people who use it, documentation written for the ones who join later, and a defined support window. Nothing we build needs us in the room to keep working.
What you are holding at launch, and after it
What is handed over
- A written spec you approve before we buildscope, screens and what "done" means — agreed up front, in language you can hold us to
- A milestone plan with acceptance criteriaprogress you can check stage by stage, not a big reveal at the end
- The application itself — web, mobile or bothdesigned, built, tested, polished and launched
- Integrations with the systems you already runnamed in the spec, connected and tested against real data
- Full ownershipsource code, accounts, keys and documentation in your name, on standard tools — no lock-in, ever
- A training session for the people who will use itplus a written guide for whoever joins after them
- A written handover, in plain languagehow it works, what it stores, and how to change a line without us
- A defined support window after launchand a plan for what the product becomes next, whoever builds it
How the build runs
- Working software, never a progress reporta demo you can click at every milestone, on your own data
- Plain-language progress notesyou always know where the build is, without translating anything
- Standard, maintainable technologyany competent developer could take it over — you are never trapped with us
- Nothing built twicewhere something you already run does the job, we connect to it instead of rebuilding it
Nothing reaches your customers until you say it can.
A launch goes wrong in one particular way: something ships that nobody on the client's side has actually used. The whole defence is to make the release someone else's to give — so it is written as a rule, and the rule has your people's names in it.
- IFthe change would reach your customers, affect financial records, or touch someone's personal data
- ORthe milestone's acceptance criteria are not all met, in front of you
- ORnobody on your side has used it on real work yet
- THENit does not go out — a named person on your side releases it, or it waits
The same rule governs any AI inside the product: wherever it drafts, answers or decides, a person approves whatever leaves your company, and anything it is unsure of goes to a named human with the full history attached rather than being pushed out on a guess.
The same five phases, with the spec as phase two.
The order is the one every service here follows; on a build it means no code exists until you have signed a document that says what "done" is, and every milestone after it ends in something you can open. Stop at any phase and you keep what has been made — the spec included.
Listen
A 30-minute call about the problem, the people who have it, and what they do today instead — then time with the people who would actually use the thing.
Map
The spec: screens, flows, integrations and what "done" means for each one. On paper, argued over, and signed by you before any code exists.
Build
Short milestones, each ending in working software you can open and steer. What you are shown is the product itself, never a progress bar describing it.
Prove
It runs on real work with the people who will live with it — the awkward cases included — until the acceptance criteria are met in front of you.
Hand over
Launch, training, documentation, and the code and accounts in your name. A defined support window, then a plan for what it becomes next.
No lock-in by design — the source code, the accounts and the documentation are yours as they are made, not signed over at the end.
Where building it is the wrong answer.
Custom software is the heaviest way to solve a problem that something simpler already solves. Neither list below wins us work, and both stay up — the alternative is finding out halfway through the build.
What it is not
- Not a rewrite of everything. Whatever already works stays. We build the missing piece and connect it to the rest, and the boundary is drawn in the spec.
- Not a platform with your logo on it. There is no FuseLoom product underneath — nothing to licence, nothing to renew, and no key held back.
- Not an app because you should have an app. If the job is done by one page, a form, or a spreadsheet with rules on it, that is what we will recommend.
- Not finished at launch. Software people actually use changes. The support window and the plan after it are part of the scope, not an extra that appears later.
When we'd say don't
- Something off the shelf already does it. If a product that already exists covers the job, we will name it — and the engagement ends there, which is the correct outcome.
- Nobody can say what "done" means. Without a spec somebody on your side owns, a build turns into an argument with a deadline attached to it.
- The process underneath is broken. New screens over a broken process give you the same problem, faster and better lit. Fix the process first.
- The date is fixed and so is the scope. One of the two has to be able to move. If neither can, one of them will break instead, and we would rather say so before you sign.
- Nobody can be spared to use it during the build. Software nobody tried before launch is software nobody trusts after it.
Four answers about risk, scope and what happens after.
Commissioning software is the decision on this site that is hardest to unwind once it is under way. These are the four that decide whether it is worth starting — the disruption, the systems it has to meet, the change of mind halfway, and who keeps it alive afterwards.
Q01 Will this disrupt how we work while it is being built?
No — we build alongside what you have rather than in place of it. Nothing you currently rely on is switched off to make room for something unfinished, and the old way stays available after launch too, until your team stops reaching for it on their own.
What we do ask for is small and specific: time with the people who will use the thing, at the spec stage and again at each milestone. That is the whole demand on your side, and it is the part that decides whether the product gets used.
Q02 Does it work with the systems we already run?
That is part of the plan from the first day rather than an afterthought. Every system it has to talk to is named in the spec — your accounting, your scheduling, your records, your messaging — and each connection is built and tested against real data before the milestone that depends on it is called done.
Where a system has no practical way to give up its data, you hear it at the spec stage, along with what the workaround would mean for you. That is a conversation we would rather have before you sign than during the build.
Q03 What if we change our minds halfway through?
You will, and the plan expects it. Seeing working software at every milestone is precisely what causes people to change their minds, and a change made because you finally saw the thing is a better change than one guessed at in a meeting.
The handling is boring on purpose. A change inside the agreed scope is absorbed. A change that adds scope is agreed in writing and approved by you before it is built — never discovered afterwards. Nothing widens quietly, and no milestone starts before you have said yes to what is in it.
Q04 Who keeps it running after launch, and what does that involve?
The application runs in your accounts, so hosting and any AI usage sit with those providers directly — we are never in between you and them. FuseLoom takes nothing for the software simply continuing to exist.
After the support window you have a real choice, which is the point of building it this way: keep us on for changes, hand it to your own developer, or hand it to another firm. The code was written to be read by whoever comes next, the documentation is in plain language, and the accounts were always yours. The build itself is agreed in writing before anything starts, and what is agreed changes only if you change what you asked for — the scope is the agreement, which is why the spec comes first.
Describe the thing. We'll name the smallest version that works.
Thirty minutes with us. Bring the idea, the spreadsheet it currently lives in, or the process everybody works around — and leave knowing the first version worth building, or the ready-made product that removes the need to build anything.
Ask us to call you backwith FuseLoom · [email protected] · if you should use something ready-made instead of building, that is what you'll be told