Internal Tools

One tool for one problem, built to replace the spreadsheet you outgrew.

Software for your own team, not for the public. I map how the work is done today, then build the smallest tool that removes the manual steps.

What this actually is

Some problems do not need a product. They need one tool that does a specific job for a specific team.

These look simple and often are not. The rules live in people's heads, and every team has exceptions nobody wrote down. Data usually sits in a spreadsheet, an old system and someone's email at the same time. The tool has to fit the way the work is already done, or it gets abandoned in a month. Permissions matter, because not everyone should see everything.

So I start by watching the current process and writing it down. Then I build the smallest version that removes the worst manual step, and we use it before adding more. Where an old system has to stay, I connect to it rather than replace it. Laravel and MySQL sit under some of this work, alongside the Next.js stack.

What you get

A written map of the current process, step by step
The tool itself, used in the browser by your team
Staff accounts with roles and access levels you control
Import from your existing spreadsheets or system
Exports and reports in the format you already use
A short handover session and written instructions for the team

Things in this category

An order and stock tracker for a small operation
A client and case manager for a professional office
An internal approval flow that replaces email chains
A reporting screen that pulls numbers from several places
A quoting tool that produces the same document every time

How this one gets built

The same six stages, said in the language of this kind of product.

You tell me the idea

A single conversation, usually about thirty minutes.

We talk until I can describe your idea back to you correctly.

We start with a conversation, in English, French or Arabic. You describe the idea in your own words. I ask questions about who it is for, what they do today, and what you want to happen. I write down what I heard and send it back for you to correct.

What you have at the endA written idea brief: the goal, the user, the assumptions, and what success means.

You see the market gaps

Usually a few days to a week.

I find out what already exists and where it leaves people stuck.

I go through the products your users already use, free and paid. I read what people complain about in reviews, forums and support threads. I look at how competitors charge. Then I write down the gaps that are real, and the ones that are not worth chasing.

What you have at the endA market and competitor report, with the gaps ranked and the evidence linked.

You see the real screens

Usually a week or two.

We decide what the product is, and you see it before it is built.

I turn the gaps into a product you can actually see. First the shape: what it does, who logs in, what each screen is for. Then clickable screens you can open on your phone. You use them, tell me what feels wrong, and I change it before any code exists.

What you have at the endA clickable prototype of the main screens, plus the agreed feature list.

You approve the plan

Usually a few days.

The build gets broken into phases, each with its own scope and price.

A big build in one piece is where projects go wrong. So I split it into phases. Each phase has its own scope, its own price and its own working result. You approve one phase before it starts. You are never asked to commit to the whole thing at once.

What you have at the endA phase plan: scope, price and result for each phase, in writing.

You watch it being built

The longest stage. Weeks to months, depending on scope.

The product gets built in order, and you see it working every week.

I build phase by phase, starting with the part that carries the most risk. Every week there is a real link you can open and use. Nothing is hidden until the end. When something takes longer than I said, you hear it from me first.

What you have at the endA working product on a live link, updated every week, with the code in a repository you own.

You launch, and I stay

Launch takes days. Staying afterwards is ongoing.

The product goes live, and I stay until it is genuinely right.

Going live is a stage, not a finish line. I move it to your domain and accounts, watch the first real users, and fix what they hit. Then I hand over what you need to run it. If you want me to keep going, I stay.

What you have at the endThe live product on your domain, with accounts, code and a short handover guide.

See all six stages in full

Built like this

Work of this kind, written as stories.

Delivered2023

Administration system

An administration system that replaced paper at a technical institute.

Laravel · Blade · MySQL · Tailwind CSS · Laravel Breeze

Read the full story

See all work

What I build

Is this what you need?

If you are not sure which of these your idea is, that is a normal question and a good reason to talk.

Tell me about your idea Or send a full brief instead

The rest of what I build