Custom internal tools
When a spreadsheet has stopped holding a department together and nothing you can buy quite fits, we build the tool your team actually works in.
The difference
A dashboard tells you what happened. This is where the work happens. We design the process before we design the screen, because a tool built on a broken process only makes the mess move faster.
Built in your accounts, on your subscriptions
Before you hand anything over
How we handle your data
-
Your systems stay yours.
The work happens in your own accounts, on your own subscriptions, under your ownership. Nothing leaves the systems you have given us access to.
-
Access is requested, never assumed.
Read only wherever the work allows it, asked for per system rather than granted in bulk, and named per person. Credentials are never shared, and your records never sit on personal devices.
-
Preparing stays separate from approving.
A second person reviews before anything is filed or closed. On payables we prepare the run and you're the one who releases it.
Who it’s for
Departments running on a spreadsheet that four people edit and nobody fully trusts, or on software that was bought for a different kind of business. Usually operations, finance, or whichever team has built the most elaborate workaround.
How we help
- 01 We start with the process, not the screen. If the workflow underneath is wrong, a better interface only hides it.
- 02 We check whether something you can buy already does this, and tell you when it does. Not every problem is worth a build.
- 03 We build on platforms your team can be trained on, rather than code only we can maintain.
- 04 You get the smallest useful version first and put it into real use, before the rest of the budget is committed.
- 05 We train the team, write it down, and keep it working as the business changes.
What you get
- One place the work happens, instead of a spreadsheet and a group chat.
- Data structured from the start, so it can be reported on later.
- A tool the whole team is trained on, not one person's private system.
- Written documentation, so the knowledge doesn't sit in one head.
- Something that can be changed when the business changes.
What owners ask about custom internal tools
Should we buy software or have something built?
Buy first, if something fits. Off the shelf software is cheaper to run and somebody else maintains it. The case for building starts when the way you work is genuinely not the way the software expects you to work, and your team has already invented a workaround to cope. That workaround, usually a spreadsheet, is the specification for the build. We tell you which side of that line you're on before you spend anything.
Which departments do you build for?
Any of them. In practice the requests cluster: operations wants job or order tracking, finance wants approvals and checks the accounting platform doesn't cover, HR wants onboarding and compliance checklists, sales admin wants quoting and handover. The pattern matters more than the department. If work is being tracked in a spreadsheet that more than two people edit, there's usually a tool worth building.
Do you build customer facing software as well?
Yes. Most of what we build is internal, because that's where the back office pain sits, but a customer or vendor portal, or a product you intend to sell, starts in the same place: what the process really is and what data it needs. We'll say plainly at the start whether what you're describing is a few weeks of work or a different order of project.
What do you build it on?
Whatever your team can live with after we hand it over. If you already work in Microsoft 365 we often build there, which keeps sign in and access rules in one place. Worth knowing up front: custom apps on that platform need their own licenses, which aren't part of a standard Microsoft 365 plan. We price that with you before anything is built, rather than after.
What happens if we stop working with you?
You keep it. It's built in your accounts, on your subscriptions, and the documentation comes with it. We would rather build something your team can run without us than something that needs us forever.
How long before we can actually use it?
The first working version is usually weeks rather than months, because we build the smallest useful slice and put it in front of the people who will use it. That version is deliberately narrow. It exists so you find out whether the design is right while changing it's still cheap.
Further reading
More under Technology
Last updated
Tell us where this one hurts.
A short call is the easiest next step. No pitch, just whether we're a fit for your back office.
Or write to hello@pptcgroup.com
Not ready for a call?
Send us last month's close.
We reply within one business day with a written list of what we'd fix.
Email your close