Your First Internal Tool: A Weekend-Sized Starter Project

How to pick a small, painful, contained process and turn it into your first internal tool quickly, without betting the business on it.

You have read about data models, workflows, permissions and governance. You are convinced. And you have no idea where to start, because every spreadsheet in the company seems tangled up with every other one.

Start small. Your first internal tool should be something you could reasonably build in a weekend, or a couple of focused afternoons. Not because small tools are the goal, but because a quick, visible win teaches you more than six months of planning, and it gives you the credibility to tackle the big one next.

What makes a good first project

The best starter project sits where three things overlap: it hurts, it is contained, and it is low risk if something goes wrong.

It hurts. People complain about it. It causes errors, delays or duplicated effort you can point to. If nobody notices the improvement, you have wasted your win.
It is contained. One team, one process, a handful of users, and few connections to other systems. Ideally under five people touch it.
It is low risk. If the tool fails for a day, nothing catastrophic happens. Payroll is a bad first project. The equipment loan log is a good one.

A fourth test is useful: you should be able to describe the process in two sentences. “People request a meeting room, and the office manager confirms it.” If your description needs a flowchart, save it for later.

Candidates that usually work

Most companies have several of these hiding in shared drives:

Process	Why it is a good starter
Equipment or kit loans	Clear records, simple states (available, out, returned)
Internal IT or facilities requests	One front door, obvious owner, easy before-and-after
Supplier contact list with renewal dates	Few users, one painful moment (the missed renewal)
Small team holiday tracker	Everyone understands it, clashes are easy to spot
Event or training sign-ups	Fixed lifespan, little integration needed

Avoid anything that feeds finance, holds sensitive personal data, or needs integrating with three other systems. Those deserve the careful approach covered elsewhere in this series.

Scope it on one page

Before you open any tool, write down the following on a single page:

The trigger. What starts the process? A request, a date, a delivery?
The records. What things are you tracking? For a kit loan: items, people and loans.
The states. What stages does a record move through? Requested, approved, out, returned.
The people. Who creates, who updates, who just needs to see it?
The one thing it must do better. Say, “nobody should ever lend out a camera that is already out.”

That last point is your success test. Write it down so you can check it later. From Rows to Records explains the second item if you have never split data into separate records before.

Build the smallest version that works

Now open your chosen platform. A no-code database platform is usually the right fit for a first project. Aim for this and nothing more:

One table per type of record, linked where needed
A form for whoever starts the process
One or two views: a list for the person running it, and a filtered view for everyone else
At most one automation, such as a confirmation message when a request arrives

Resist adding fields “in case”. Every extra field is something people must understand and fill in. If you find yourself building a dashboard on day one, stop and go back to your one-page scope.

Say you are building a kit loan tracker for a small marketing team. Items, people and loans as three tables; a loan form with item, borrower and return date; a view of everything currently out, sorted by return date. That is a Saturday afternoon of work, and it solves the “where is the good microphone?” problem for good.

Move the data and switch over

Bring across only what you need. For a first project, that might be the current items and any loans still open. History can stay in the old sheet, which you then mark read-only and rename with “ARCHIVE” at the front so nobody edits it by accident.

Pick a switchover day and tell everyone. Keep the message short: what is changing, where the new tool is, who to ask. Then be available that first week to answer questions quickly. A first tool lives or dies on whether the first three people who try it have a good experience.

Judge it after a month

After four weeks, check your success test. Has the one thing improved? Ask the users what they like and what annoys them. Look at the data: are records complete, or are fields being skipped?

You are also learning about your platform. What was easy? What fought you? Where did you need help? These lessons are what make the second project faster, and they will feed directly into bigger decisions. Choosing an Internal Tool Platform has a checklist worth revisiting with real experience behind you.

If the first tool did not work, that is useful too. A failed weekend project costs a weekend. A failed six-month migration costs a lot more.

Use the win

When it works, tell people. A short note to your manager, a two-line message in the team chat, a mention in the next team meeting. “We replaced the kit loan sheet; nothing has gone missing in a month.” That is the kind of evidence that makes Getting Buy-In much easier when you are ready for something bigger.

Then pick the next process, a little bigger and a little more connected than the first.

Where to start this week

List five spreadsheets that annoy people and score each for pain, containment and risk.
Pick the winner and write its one-page scope, including the single thing it must do better.
Block out a half-day to build the smallest version, and invite one future user to try it before launch.
Set a calendar reminder four weeks after switchover to check the success test.