Direct answer
Before an internal tool is built, write down the job it must do and who does that job today, then the users and what each may do, the data it reads and writes, the workflow steps including exceptions, the approvals and record you need, the devices people work on, what it replaces, and what stays out of version one. Finish with what you will hand a builder: screenshots, sample files and a named owner on your side. That is a set of requirements a builder can quote against. It is deliberately about the people and the work, not about screens or technology, because the screens follow from the work. If you are still deciding whether the tool is worth building, start with the internal tool business case instead.
Why the checklist starts with people, not features
The common failure is a tool designed from a meeting room. Someone describes the process as it is supposed to work, the tool follows that description, and the people who do the work discover on day one that the real process has steps nobody mentioned. Ask the people who do the work to show you, not tell you. Watching one person handle one real case usually reveals more requirements than an hour of describing the process in general terms.
The job the tool must do
Write one or two plain sentences: who does what, using which information, to produce which result. Then note how it is done today, whether that is a spreadsheet, a shared inbox, a paper form or a mix. If you cannot describe the job in a couple of sentences, the tool will not have a clear centre, and the first version will try to be everything. For a survey of what kinds of internal tools exist, see internal business tools.
Users and roles
List every kind of person who touches the tool, and for each one say what they can see, what they can change and what they can approve. Include the occasional users, such as a manager who only reads a summary or an auditor who needs a view once in a while. Also name who adds and removes users, because that person is easy to forget until the first leaver. Where roles get detailed, roles and permissions in a web application covers how to keep the set small.
Data it reads and writes
For each piece of information the tool handles, note where it lives now, who keeps it correct and whether the tool will read it, write it or both. Two questions matter most: which system is the source of truth for each item, and what happens when two systems disagree. If the data needs preparing before anyone can build, prepare your data before a software project covers the samples a builder will ask for.
Workflow steps and exceptions
Write the normal path as a short sequence, then list the exceptions: the case that comes back for correction, the request that needs a second opinion, the item that arrives incomplete, the person who is away. Exceptions are where an internal tool usually earns its keep or fails, so ask people what goes wrong, not only what usually happens. Do not try to design every exception in advance. List the ones people actually meet and mark the rest as handled by a person.
Approvals and the record you need
Note which steps need someone's sign-off, who that someone is, and what happens when they are unavailable. Then decide what record you need afterwards: who did what, when, and on the basis of which information. If nobody will ever look at the history, do not build for it. If an auditor, a customer or a manager will, say so now, because adding a record afterwards is harder than building it in.
Devices and where people work
State where the tool will be used: at a desk, on a phone, on a shared screen, on a warehouse or workshop floor, possibly with gloves, poor signal or a scanner. A tool designed for a desktop and then used on a phone at a loading bay is a common and avoidable disappointment. Note any device that people already carry and that the tool should use rather than replace.
What it replaces, and what stays in spreadsheets
Be explicit about what the tool retires and what it does not. Some spreadsheets will stay, and that is fine: a tool that tries to absorb every last file tends to grow past what anyone can finish. Write down which files, inboxes or paper forms stop being used on the day the tool starts, and who will tell people. If the tool is meant to replace a specific spreadsheet, when to replace spreadsheets discusses what that involves.
What to leave out of version one
Make a second list of things you want eventually but will not ask for now: extra reports, integrations with systems you rarely use, rules for rare cases, a polished look. This list is not a rejection. It is what lets the first version be small enough to finish and use. Revisit it after people have used the tool for real. A first release that handles the main path well beats one that handles every path badly.
What to give a builder
Hand over what you have rather than a summary of it: screenshots of the current process, the actual spreadsheet or a copy with sensitive fields removed, a few real examples including a messy one, and the names of the people who know the exceptions. Name one person on your side who can answer questions and decide. A builder with a real sample and a named decision-maker can give you a much better-grounded proposal than one working from a description.
Where LATYNEX fits, and when it does not
LATYNEX scopes and builds internal tools as web applications. We read the checklist, the samples and the process as part of scoping, tell you what we think version one should be and what should wait, and agree one scope and one price in writing before work starts. LATYNEX is a remote, English-language vendor, so we agree the communication route at the start. See internal request portals for one common shape.
We are not the right fit when the need is met by an off-the-shelf app you already pay for, or when a single person keeps a spreadsheet that works and nobody else depends on it. Not every internal need requires a custom build, and low-code vs custom internal tools discusses how to tell.
Questions
What is the most important requirement for an internal tool?+
A clear statement of the job it does and who does that job today. Most other requirements follow from it, and a tool without that centre tends to grow without finishing.
Do I need to write screens or wireframes first?+
No. Describe the people, the data and the workflow. A builder can propose screens from that. Screenshots of what you use today are more useful than sketches of what you imagine.
Should everything go into the first version?+
No. Keep a separate list of what can wait. A small first version that people actually use gives you better information about what the next version needs.
What if our process is not clean or consistent?+
That is normal. Describe how it is actually done, including the exceptions, and mark which variations are real and which are habits you would happily drop.
Do we always need a custom tool?+
No. If an existing app you already have covers the job, use it. A custom build makes sense when your process is specific and the off-the-shelf options force workarounds.