Build an internal business tool
An internal tool is software only your team uses, such as an admin panel, a dashboard or an approval flow. The best start is one painful workflow, replaced by one clear screen. ErdiBuilds is an open marketplace where clients post app, SaaS, website and game projects, see which independent developers from the EU fit best based on what they have already built, and pay per milestone.
Last updated:
Where internal tools pay off
Look for work that is repeated every day or week and lives in spreadsheets, shared inboxes or chat threads. Examples are order handling, scheduling staff, quotes, inventory counts, onboarding checklists, reports for a manager and an admin view for a product you already run.
Users are known and few, so the interface can be plain and fast. What matters more is who may see and change what, how the tool connects to your other systems and what happens to your data. If customers will use it too, it becomes a web app or a SaaS.
Build, buy or low-code
- Buy when an existing product already does most of the job and you can live with its limits.
- Use a low-code platform such as Retool or Bubble for simple screens on top of data you already have. See Bubble developers.
- Choose custom code when the workflow is special, the rules are complex or the tool will grow with the business.
A developer who is open to all three is more useful than one who only sells their own favourite. Find My Stack can also help you think through options.
Typical technologies
- Next.js or React for the screens.
- Postgres with Supabase for data, login and file uploads.
- Single sign-on so people do not need another password.
- Role based access and an audit log of important changes.
- Connections to tools you already use through their APIs, plus scripts in Python or Node.js for data jobs.
An example plan in milestones
A small tool can go live in stages so your team starts earlier. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks. Milestones are from 50 to 2,000 each in your project currency.
| Topic | Example timing | What happens | Who joins |
|---|---|---|---|
| Discovery | For example, week 1 | Walk through the current process, list fields, rules and exceptions, agree the first screen | The two people who do the work today |
| First workflow | For example, weeks 2 to 4 | Login, roles, the main screen, data import from the spreadsheet | A small pilot group |
| Connections | For example, weeks 5 to 6 | Links to email, shop, CRM or accounting, notifications, exports | Whoever owns those systems |
| Rollout | For example, weeks 7 to 8 | Fixes from the pilot, short guide, backups, handover | The whole team |
Discovery
- Example timing
- For example, week 1
- What happens
- Walk through the current process, list fields, rules and exceptions, agree the first screen
- Who joins
- The two people who do the work today
First workflow
- Example timing
- For example, weeks 2 to 4
- What happens
- Login, roles, the main screen, data import from the spreadsheet
- Who joins
- A small pilot group
Connections
- Example timing
- For example, weeks 5 to 6
- What happens
- Links to email, shop, CRM or accounting, notifications, exports
- Who joins
- Whoever owns those systems
Rollout
- Example timing
- For example, weeks 7 to 8
- What happens
- Fixes from the pilot, short guide, backups, handover
- Who joins
- The whole team
The weeks are for illustration. Developers set the length of each milestone in their proposal, and each real milestone runs 1, 2, 3, 4, 6 or 8 weeks. Involving real users early prevents the most expensive rework.
What belongs in the project description
- The current process, step by step, including the workarounds.
- How many people use the tool and their roles.
- Systems it must read from or write to, with names and, if you know it, how access works.
- Sample data or screenshots of the spreadsheets in use. Remove personal data first.
- Rules about data protection, for example personal data of customers or staff.
- What counts as success, for example fewer manual steps or faster answers.
How to recognise a suitable developer
A good fit asks about your process before they suggest software. They explain how permissions work, how data is backed up and how you can keep using the tool if they become unavailable. Past work with dashboards, imports and integrations is more relevant than flashy design.
The match score shows plain reasons for each proposal. A developer needs 40 or more to apply, and 80 or more gets a Top match badge. Developers are independent professionals, not our employees.
Frequently asked questions
Can the tool connect to our existing software?
Usually, if that software has an interface for it. Name the tools in your brief and ask the developer to check what access each one offers.
Link to this answerHow do we keep company data safe?
Through logins, roles, backups and access only for people who need it. Ask the developer how they handle each of these, and create the hosting accounts yourself.
Link to this answerShould everything be built at once?
No. Start with one workflow, learn from the pilot and add more in later milestones. That keeps risk and cost visible.
Link to this answerWho owns the tool when it is finished?
Unless both sides agree otherwise in writing on the platform, the rights to the result of a milestone pass to the client once that milestone is paid in full. Keep the code in a repository and the hosting in accounts that belong to your company.
Link to this answerWho maintains it afterwards?
That is up to you. You can agree a follow-up milestone with the same developer or hire another one. Readable code and a short handover note make that easy.
Link to this answerRelated pages
- Build a web app with an independent developerHow to plan a browser-based web app: common technologies, an example milestone plan, what to write in the brief and how to judge a developer.
- Build a SaaS with an independent developerPlan a SaaS product: accounts, subscriptions, technologies, an example milestone plan, what to write in the brief and how to pick a developer.
- Hire a Supabase developer for your backendSupabase stores data and handles logins for apps. Learn what a Supabase developer does, what to ask, and how projects and matching work.
- Hire a Bubble developer for your appBuild or fix a no-code app with Bubble. What a Bubble developer does, the limits to know, what to ask and how matching works.
- How to Write a Project Brief for a DeveloperA good project brief fits on one page: goal, users, must-have features, examples and limits. Here is what to include and a free tool to draft it.
- Hire a Developer to Add New FeaturesYour product works and now it should do more. Learn how to describe a feature, plan it in milestones and pick a developer who fits your code.