Refract Group2026
Internal tools
The tools your team keeps asking for.
Internal software for the work between your systems: reviewing, finding, checking and handing things over. Start with one recurring task and the people responsible for it.
Find the work worth automating
A useful internal tool starts with a clear workflow. We look at what comes in, the decisions a person makes, the systems involved and what has to happen when something goes wrong. That gives the build a boundary and gives your team a way to judge it.
- Operational interfacesA focused view of the records, tasks and exceptions a team needs to act on.
- Connected workflowsIntegrations between existing tools where their APIs, permissions and data quality support the job.
- Review and approvalClear ownership, validation and human checkpoints for decisions that need judgement.
- HandoverAgree documentation, access, maintenance and responsibility for failures before the tool becomes essential.
A working example: our outbound system
Our published account of building outbound for Refract and Cyna explains how research, prospect assessment and outreach preparation connect. It is a concrete example of the workflow thinking behind internal tools, rather than a promise of the same results for every business.
Read how the outbound system worksBuild around the real process
- ObserveFollow a representative task from its trigger to completion, including manual workarounds.
- MapIdentify the source of truth, required permissions and the decisions that stay with a person.
- BuildImplement a bounded version and exercise ordinary, missing-data and failure cases.
- OperateReview it with the team, document recovery and agree how changes will be maintained.
Ways to start
Bring a recent example of the task, the systems it crosses and the point where work gets stuck.
A workflow review
Map one recurring process and decide whether a configuration change, integration or custom tool is warranted.
A focused build
Design and build one agreed workflow, with access, failure handling and handover included in the scope.
Ongoing improvement
Review use and support needs, then extend the tool where the evidence supports it.
Questions before we start
Ask usNot necessarily. We first check whether configuration or an integration can solve the problem. A custom build makes sense when the remaining workflow is valuable enough to maintain.
Yes, where it helps with tasks such as drafting, extracting or classifying information. We agree evaluation examples and review points; actions with meaningful consequences need explicit permission and recovery behaviour.
Ownership, source-code access, hosting and support are agreed in the scope. We can hand over to your team or define an ongoing maintenance arrangement.
The articles describe our work and experiments. They are not a public software catalogue. Contact us with your workflow to discuss a demonstration or a suitable project.
Compare the complete task before and after: time spent, manual corrections, exceptions and maintenance effort. The baseline and measurement period depend on the workflow.
