# 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. Canonical: https://erdibuilds.app/build/internal-tool Last updated: 2026-11-06 (November 6, 2026) ## 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](https://erdibuilds.app/build/web-app) or a [SaaS](https://erdibuilds.app/build/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 (A tool where you assemble screens and logic with a visual editor and write little code.) such as Retool (A low-code tool for building admin panels and dashboards on top of databases and APIs.) or Bubble (A no-code platform for building web apps visually.) for simple screens on top of data you already have. See [Bubble developers](https://erdibuilds.app/hire/bubble). - 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](https://findmystack.app/?project_type=internal-tool) can also help you think through options. ## Typical technologies - Next.js (A React framework that renders pages on the server and in the browser, with routing and API routes built in.) or React (A JavaScript library for building interactive user interfaces from components.) for the screens. - Postgres (A widely used open source relational database.) with Supabase (An open source backend with a Postgres database, user login and file storage.) for data, login and file uploads. - Single sign-on (Logging in with the same company account for many tools, for example through Google or Microsoft.) so people do not need another password. - Role based access (Rules that give each person only the permissions of their role, such as viewer, editor or admin.) and an audit log of important changes. - Connections to tools you already use through their APIs (Interfaces that let one program read data from or send data to another.), plus scripts in [Python](https://erdibuilds.app/hire/python) or [Node.js](https://erdibuilds.app/hire/nodejs) 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. **Example phases for an internal tool** | | 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 | 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 (A number from 0 to 100 that shows how well a developer fits your project, with plain reasons such as shared technologies, similar past work, budget fit and availability.) 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. ### How 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. ### Should 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. ### Who 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. ### Who 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. ## Related - [Build a web app with an independent developer](https://erdibuilds.app/build/web-app): How 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 developer](https://erdibuilds.app/build/saas): Plan 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 backend](https://erdibuilds.app/hire/supabase): Supabase 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 app](https://erdibuilds.app/hire/bubble): Build 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 Developer](https://erdibuilds.app/guides/how-to-write-a-project-brief): A 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 Features](https://erdibuilds.app/help/add-features): Your 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.