How to build a small internal tool instead of renewing a big one

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, Adobe Acrobat and 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.

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.

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.

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 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.

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 and compare them with the renewal you are trying to stop. If the answer is close, renew the product and spend the hours elsewhere.

What you spend building a tool for your own use may be expensed as it is incurred or capitalized as 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.