--- title: "How to build a small internal tool instead of renewing a big one" description: "When one narrow job justifies a custom build, how to scope it to two screens, review AI-written code, and what to ask your CPA." canonical: "https://lopifi.com/savings/how-to/build-a-small-internal-tool" --- # How to build a small internal tool instead of renewing a big one > When one narrow job justifies a custom build, how to scope it to two screens, review AI-written code, and what to ask your CPA. Source: https://lopifi.com/savings/how-to/build-a-small-internal-tool Part of: Lopifi — US GAAP books on autopilot, checked by a CPA (https://lopifi.com) --- Series: Move and replace. Reviewed 2026-10-25. Some subscriptions are hired for one job and used for a sliver of what they offer. A small tool for that one job can be cheaper to hold and easier to understand. It is also software you now own forever. This guide covers when to build, how small to keep it, and how to use AI coding agents without losing control of the result. ## Run your numbers - [Build vs buy break-even](https://lopifi.com/md/tools/build-vs-buy): Build a small tool or keep paying for one: the cost of each over your horizon and the month the build breaks even. ## Is this a build job? If most of those are true, a build is worth pricing. If the job touches payments, payroll, tax filing or customer data you must protect by contract, start by asking whether an existing tool already does it, and bring in someone qualified before you build anything. Several of the apps in our catalog, such as [Salesforce](https://lopifi.com/savings/salesforce), [Adobe Acrobat](https://lopifi.com/savings/adobe-acrobat) and [FileMaker](https://lopifi.com/savings/filemaker), list a small custom build as one of the options. - One narrow job, named in a sentence: for example, "add a PDF cover page and merge two files". - A few people do it often, and you can list them. - You can describe the inputs and the outputs on paper. - The data is yours already, in a form you can export. - Someone will own it by name and has the time. ## Scope it to the two screens people use Watch the people who do the job for a week and write down the screens they open. Almost always it is two: one to put something in, one to see what is there. Build those and nothing else. 1. **Screen one: the list.** A page that lists the records, with search and a way to export to a spreadsheet. 2. **Screen two: the form.** A form that adds or changes one record, with the checks the job needs written down once. 3. **Sign-in.** Sign-in through the same account system the company already uses, so removing a person removes their access. 4. **Everything else waits.** Anything not on the list of screens goes on a later list. Reports, dashboards, notifications and roles are each a project of their own. ## Own the data Moving data into the tool is the part to rehearse. Copy, never move, and keep the old system read-only until the new one has done a real month of work. - Keep the records in a database you control, in a format another tool can read. - Back it up somewhere other than where it runs, and restore it once to prove the backup works. - Keep a one-click export so leaving your own tool is never harder than leaving a vendor's. - Write down where it is hosted, who can reach it and where the secrets are kept. ## Using AI coding agents responsibly Accounting software is a good example of why review matters. A plausible-looking amount column or a rounding shortcut is a correctness problem the agent will not flag. Money handled by a tool should be integers in the smallest unit of the currency, and the people who sign your books should have seen how the tool computes anything they rely on. [Vibe accounting](https://lopifi.com/vibe-accounting) describes how Lopifi approaches that for ledgers. - Give the agent the written scope and the list of screens. A request for "an internal tool" returns something larger than you need. - Read every change before it merges. If nobody on the team can read the code, the team cannot own the tool. - Ask for tests that describe your rules in plain examples, and run them yourself. A passing test only proves what it checks. - Use real examples from the job, with the awkward cases, and compare the output with what a person produced by hand. - Keep secrets out of the code, out of prompts and out of chat. OWASP's guidance is to keep them in a managed place, rotate them, and treat one found in code or logs as exposed and remove it. - Give the tool and the agent only the access the job needs, and never a production login that can change books or move money. - Pin the dependencies you use and check their licenses; see [open-source licenses for founders](https://lopifi.com/md/savings/how-to/open-source-licenses). ## The cost that arrives after launch Hosting, updates to the framework and libraries, a person who understands it, and the day someone asks for one more field. Put those hours in the sheet from the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math) and compare them with the renewal you are trying to stop. If the answer is close, renew the product and spend the hours elsewhere. ## In the books What you spend building a tool for your own use may be expensed as it is incurred or [capitalized](https://lopifi.com/md/glossary/capitalization) as [internal-use software](https://lopifi.com/md/glossary/internal-use-software), depending on the facts, including what stage the work is in and what it covers. Time spent on planning and on ongoing maintenance is treated differently from time spent building. We do not apply the rules here. Keep time records by task, keep the invoices of any contractors, and ask your CPA before you start. ## Common questions ### When does a build make sense? When the job is narrow, a few people do it every week, and the product you pay for is mostly unused around it. If you need most of what the product does, or the data feeds your books, a build is usually the wrong answer. ### Can an AI coding agent just write it? It can write a first version quickly. It does not know your rules, and it can produce code that looks right and is wrong. Someone on the team has to read it, run it against real examples and own it afterward. ### What do we do with passwords and API keys? Keep them out of the code and out of prompts and chat. OWASP's guidance is to keep secrets in a managed place, rotate them, and remove any that show up in code or logs. Use a password vault or your host's secret store, and give the tool only the access its job needs. ### What does it cost after it is built? The tool is yours to maintain: updates, a person who knows how it works, and a plan for when that person leaves. Count those hours before you start, with the formula in the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math). ### Do we capitalize the cost of building it? Possibly. Whether the work is expensed or capitalized as internal-use software depends on the facts and on the stage of the project. That is a question for your CPA before you start, not after. ## Sources - [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (read 2026-10-25) ## Keep going - [The honest math of self-hosting](https://lopifi.com/md/savings/how-to/self-hosting-honest-math): A formula for the real yearly cost of running open-source software yourself, a worked sample, and when you should not self-host. - [Software approval policy](https://lopifi.com/md/savings/how-to/software-approval-policy): A one-page software approval policy a ten-person company can adopt: who may buy, card and trial rules, an owner per tool, and a checklist. - [Dropbox migration, in depth](https://lopifi.com/md/savings/how-to/dropbox-migration): A start-to-finish plan for leaving Dropbox: inventory, destination, pilot, copy and verify, shared links, cutover, cancellation and how the books treat it. - [Open-source licenses for founders](https://lopifi.com/md/savings/how-to/open-source-licenses): MIT, Apache, MPL, GPL and AGPL in plain English for founders who run open-source software instead of paying a license, and what each asks you to do. - [Run the free audit](https://lopifi.com/savings/audit) - [All how-to guides](https://lopifi.com/md/savings/how-to) *General information, not tax, legal or accounting advice.*