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
- human gates 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
States, 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, modelled as a workflow template.
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 artifact of the run 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 inside the workflow and land in the record as artifacts you can read, comment on and reject.
In the record research_report, prd, design_package
- 03
Design approval
A human gate. The run waits until you approve the design package. Nothing is built that the record does not say is being built.
In the record design_approval transition, logged with the approver
- 04
Development
Implementation runs as jobs on runners in short cycles. You see every transition 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 escalate instead of slipping through.
In the record qa_report, review_report
- 06
Release and operation
A release candidate leaves the loop 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, released
Internal tool options
| Item | Spreadsheet | Low-code platform | Sydeso |
|---|---|---|---|
| Fit to the process | Whatever the owner built | What the platform allows | Modelled with the operators and approved by them |
| Enforcement | None | Some | States, 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 |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
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 transition are part of the workflow template 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 record and the platform 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.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
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