There is a spreadsheet somewhere in your company that runs a process it was never meant to run. There is a sticky note, or a Jira ticket nobody opens, that says “build the tool” with a quarter next to it. The quarter has been crossed out more than once. This post is about that tool.
Why it never gets built
Not because it is hard. Internal tools are usually the easiest software a company needs: one team of users, known requirements, no marketing page. They do not get built because they never win the prioritisation meeting. Customer-facing work has revenue attached. The internal tool has a cost saving nobody has measured, so it loses to the feature with a number on it, every quarter, forever.
Meanwhile the spreadsheet grows a fortieth tab, the onboarding checklist lives in someone’s head, and the one person who knows how the export works goes on holiday.
The seven we see most often
- The lead-capture form with an admin view. Leads arrive by email and get retyped into a sheet. The tool is a form, a table, a status field and a notification.
- The booking widget. A service business taking bookings by phone and WhatsApp, with double-bookings to match.
- The inventory tracker. Stock levels in a spreadsheet that is right on Monday morning and wrong by Tuesday.
- Time tracking with invoicing. Hours in one system, invoices in another, and a monthly afternoon spent reconciling them.
- The feedback collector with moderation. Customer or employee feedback that arrives through four channels and is reviewed through none.
- The lightweight CRM. Not Salesforce. The twelve fields your sales process actually uses, with a pipeline view.
- The legacy module nobody will touch. One part of an older system that everyone routes around, waiting for a migration that is always next year.
What it takes to get one built at no cost
Blacksmith.Works builds internal tools for companies with mentored junior developers, supervised by senior engineers. You pay nothing for the software. Here is what the engagement actually involves, because “free” deserves a full sentence.
- A brief. Goals, success criteria, the systems we need to integrate with, and a target timeline if you have one. Enough for our senior engineers to write a solution architecture before anyone writes code.
- A point of contact. Someone on your team who can answer questions during the build, roughly one to two hours a week, over Slack, email or Jira, whichever you already use.
- A brand-reference agreement. When an apprentice successfully ships their part, they may list your company as a reference on their CV and portfolio: your logo and the project name, never your intellectual property. A short testimonial is optional and entirely up to you.
In return you get the software, with source code, deployment instructions and a handover. No licensing fees, no service invoices. If an apprentice does not perform, we replace them; you do not carry the hiring risk or the management overhead.
How big can it be
Three sizes are free for your company. A Starter project is a single internal tool or widget, four to six weeks, one apprentice with a mentor. A Professional project is a full internal app or a feature inside an existing product, with multi-table data, role-based access and a third-party integration, six to ten weeks. An Enterprise project is a production-grade module or a whole product with real architecture, CI/CD and observability, ten to sixteen weeks, built by a small apprentice team under a senior lead.
If the work is too time-sensitive for apprentice pacing, there is a fourth option, a paid Mentor Build, where senior engineers execute it directly. Quoted after a scoping call.
Where to start
Do not spend an afternoon writing a specification. Send the brief you have, even if it is three sentences; working out the size is what the scoping call is for. We come back within a few business days with a feasibility note, a proposed architecture and a target timeline. Then you cross the quarter off the sticky note for the last time.
Submit a project, or read the full companies page first.