Replace the spreadsheet sprawl with tools your team actually uses
Internal tools are the software your team uses to run the business: scheduling boards, admin panels, approval workflows, dashboards, the screen the ops team lives in. They replace the fragile middle layer most companies run on — the shared spreadsheet with forty tabs, the process that exists as email threads and memory.
Willowark builds internal tools by sitting with the people who will use them. The first version covers the real workflow — including the exceptions users mention in passing that turn out to be half the job — and ships in weeks. We build custom where the workflow deserves it and use admin-panel frameworks where they genuinely fit, because a tool's budget should match its job.
Software EngineeringHow the work gets done
The same way every time: scope, build, hand over.
The engineering is unglamorous and load-bearing: authentication against your existing Microsoft or Google accounts so there is no new password, role-based views so a supervisor and an operator each see what they need, audit trails on the records that matter, and integrations that pull ERP or CRM data in so the tool reflects reality instead of becoming another copy of it.
Adoption is the only metric that counts. An internal tool succeeds when the old spreadsheet stops being updated because nobody needs it — so we watch usage after launch, fix the friction users actually hit, and iterate. Internal tools are never finished so much as continuously fitted to the operation, and we structure support accordingly.
Scoping an internal tool is mostly a matter of watching the job get done. We spend time with the people who will use it, follow a few real cases from start to finish, and write down the steps, the exceptions, and the places where someone re-types something. From that we pick the narrowest tool that removes the worst of it. The trade-off we weigh most often is custom versus framework: an admin-panel builder gets a CRUD screen up fast but fights you on anything unusual, while custom code costs more up front and bends wherever the workflow does. We choose per screen, not per project.
The way internal tools fail is quiet: the tool works, but the spreadsheet keeps living alongside it because one column the tool lacks, or one person who was never trained, keeps the old habit alive. We design against that by tracking the specific artifacts the tool is meant to retire and checking, a few weeks after launch, whether they are actually gone. Handover includes the source, the deployment setup under your accounts, and a short guide written for the supervisor who will field questions, not just for engineers. Small tools should have small operating burdens, and we keep them that way.
Scope it in writing
What we agree before work starts
- Working internal tool deployed and connected to your data sources
- Single sign-on with your existing identity provider
Build with checkpoints
Working results, not slide decks
- Role-based permissions and audit trails
- Integrations reading from and writing to your systems of record
Hand over something you own
Documentation, source, and training
- Post-launch iteration based on real usage
- User guide and short training session for the team running the tool day to day
Sound familiar?
Where internal tools earns its keep.
A production scheduler juggling a whiteboard, a spreadsheet, and a printout that disagree by noon
A manager approving purchases by email with no record of what was approved when
A customer service team looking up order data across three systems for every call
A field team filling out paper forms that get re-keyed into a system a week later
Ask about Internal Tools
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
AI operating software for training operations
Components:
- Schedulers (training ops): The people running the training operation.
- Operating software (AI assistance): The operating software, with AI assistance built in.
- Cloud services (distributed): Distributed cloud services behind the application.
- Training game (learning): The training game the software connects to.
Connections:
- Schedulers to Operating software
- Operating software to Cloud services
- Operating software to Training game
A global automotive manufacturer's training operation · Automotive
AI operating software for training operations
AI operating software for the manufacturer's training schedulers — removing manual scheduling labor and logistics tracking, saving hundreds of hours per year — plus a training video game built to help trainers perform better. Used across the manufacturer's training organization.
Read the case study →Common questions
Asked before every internal tools project.
Why build when we could buy something off the shelf?
Sometimes you should buy, and we will say so in discovery. Building wins when the workflow is specific to you, when off-the-shelf tools would force your process into theirs, or when the tool must sit on your existing systems and data. The worst outcome is buying a product and then paying to customize it into what a custom tool would have been.
How fast can we have something usable?
Weeks, typically. Internal tools have a known user base and a known workflow, which removes most of the discovery risk that stretches product timelines. We ship a working core early, let your team use it, and build the rest guided by what they hit — faster, and it produces a better tool than specifying everything up front.
What about changes after it's built?
Expect them; a good internal tool generates requests because people use it. We build with clean structure and tests so changes are cheap, and we offer light ongoing arrangements for exactly this. Tools we build are also handoff-ready if you would rather your own team carry them forward.
Can it pull data from our ERP or accounting system?
Usually, yes. Most systems of record expose an API, a database view, or at minimum a scheduled export, and we build the tool to read from whichever is available so it reflects live data rather than a copy. Writing back is more delicate — we scope it carefully, validate against the target system's rules, and log every write. Where a vendor offers no access at all, we tell you early and weigh the alternatives together.
Can we start with one department and expand later?
That is usually the best way to do it. A tool built for one team with one clear workflow ships faster, gets adopted faster, and teaches everyone what the second team will actually need. We structure the data model and permissions so a second department is an extension rather than a rebuild — shared records, separate views, roles that keep each group in its lane. Expansion typically happens in short follow-on phases once the first team is running on it.
Where this sits
Internal Tools, inside a software engineering system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Users reach a web app that talks to an API over a database, with background workers for the slow work and integrations to the systems already in use.
Components:
- Users: Staff, customers, or both.
- Web app: The interface: fast, accessible, works on a phone.
- API: Typed, versioned, authenticated.
- Database: Postgres, usually. Backed up, migrated, monitored.
- Workers (jobs, queues): Reports, syncs, emails — anything that should not block a click.
- Integrations (existing tools): Accounting, CRM, email, payments.
Connections:
- Users to Web app over REST
- Web app to API over REST
- API to Database over SQL
- API to Workers over events
- Workers to Integrations over webhook, both directions
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.