Internal tools development
Internal tools built around the process, not the other way round.
The software your team runs the business on deserves the same care as the software you sell. We model the process first, then build the tool that enforces it, and we keep running it.
Start a project- week of discovery with the people who do the work
- 1
- sign-offs before anything changes
- 2
- of changes logged with an actor
- 100%
What a well-built internal tool changes
-
The workaround goes away
The spreadsheet, the shared inbox and the manual re-keying are replaced by the tool they were standing in for.
-
The process is enforced, not described
Stages, transitions and approvals are in the software. Work cannot skip a step.
-
One source of truth
Integrations pull from the systems you already run, so the tool shows what is true rather than a copy of it.
-
Audit by default
Who changed what, when, and who approved it. Compliance stops being a project.
-
Built with the operators
Discovery is with the people who do the work. The design package is theirs to approve.
-
Operated, then handed over cleanly
We run it after launch and the record lets your team take it over when ready.
When it is time to build the tool
Internal tools are usually built late, after the workaround has become the process.
- 01
The spreadsheet has an owner
One person understands it and everyone is afraid of the day they leave.
- 02
Approvals live in email
Sign-off is a reply, and finding it later is a search.
- 03
Three systems disagree
CRM, billing and operations each hold a version of the customer, and someone reconciles them.
- 04
Onboarding takes a month
Because the process is in people’s heads, not in the software.
- 05
You bought a tool and configured it into a corner
The low-code platform worked until the process changed.
- 06
An auditor asked who approved it
And the answer took a week.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
Internal tools we build
-
Admin panels and back office
The screens your team uses to run accounts, orders, content or cases, with the permissions the roles need.
-
Approval and review flows
Gated processes with logged approvers.
Read more -
Operations dashboards
What is true right now, pulled from the systems of record rather than copied into a sheet.
-
Integrations
The connections that make the tool reflect reality.
Read more -
Agents inside the tool
Classification, drafting and triage as bounded jobs with reviewable output.
Read more -
Replacing the spreadsheet
Carefully. The data moves with its history, and the old sheet stays readable until nobody opens it.
How an internal tool is built
- 01
Discovery
A week with the people who own the problem. We write the feature request as the first document of the engagement and agree what done means before anything is designed.
In the record Feature request, scope, success measures
- 02
PRD and design package
Research, requirements and design are produced and land in the record as documents you can read, comment on and reject.
In the record Research report, PRD, design package
- 03
Design approval
A human gate. Work waits until you approve the design package. Nothing is built that the record does not say is being built.
In the record Logged approval, with the approver
- 04
Development
Implementation runs in short cycles against the approved scope. You see progress as it happens, with the implementation package growing in the record.
In the record Implementation package
- 05
Automated QA and manual review
Automated QA runs first and writes a report. Manual review is the second human gate. Failures go to a person instead of slipping through.
In the record QA report, review report
- 06
Release and operation
A release candidate ships only after both gates pass. We deploy it, monitor it and operate it, and the next request starts the next run.
In the record Release candidate, release log
Internal tool options
| Item | Spreadsheet | Low-code platform | Sydeso |
|---|---|---|---|
| Fit to the process | Whatever the owner built | What the platform allows | Modeled with the operators and approved by them |
| Enforcement | None | Some | Stages, transitions and gates |
| Audit | Version history | Varies | Every change with its actor |
| Integration | Copy and paste | Connectors | Direct, documented APIs |
| When the process changes | Edit the sheet | Reconfigure, if possible | A new feature request, a new run |
| Cost model | Free, then expensive | Per seat | Per project, then operation monthly |
How an engagement is structured.
-
Week one
Discovery
A week with the people who own the problem. We write the feature request, the PRD and the design package, and agree what done means.
- Ends in a PRD and a design package you own
- You approve it before anything is built
- Comes with a price for the build
-
After approval
Build
Development in short cycles against the approved scope. Automated QA writes a report on every release candidate and a person reviews it before it ships.
- Priced per project against the PRD
- Changes are new feature requests, priced the same way
- Every document is yours as it is produced
-
After launch
Operate
We deploy it, monitor it and run releases, month to month. Production is where the next feature request comes from.
- Monthly, separate from the build
- Take it in-house whenever you are ready
- The record comes with it
Questions
- Can you connect to our existing systems?
- Yes. Integrations are part of the design package. The tool reads from and writes to the systems you already run, through documented APIs.
- How do you handle permissions?
- Roles and what each may change are part of the design you approve. The audit log records who did what.
- What about the data in the spreadsheet?
- It moves with its history during discovery and development, and the migration is verified at QA before the gate.
- Can our own team change the tool later?
- Yes. The code, the accounts and the record are yours. The next change is a feature request your team can run.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Where does the work live?
- In your accounts. Code in your repository, infrastructure in your cloud, documents where your team can read them. We bring the process, not a dependency.
- What happens to the work if we stop?
- You keep everything: code, infrastructure, requirements, design packages, QA and review reports. There is no handover because none of it was ever ours.
Show us the spreadsheet.
Tell us what the team runs on today and what breaks. We reply with the tool we would build and the gates we would put in it.
Start a project