Skip to main content

Dashboards & Internal Tools

Admin panels and reporting screens built for daily use — order, inventory and payment views that stay readable as the numbers move. Fixed price, React and Node.

Get a fixed quoteFree 30-min call · scope agreed upfront

Admin panels and reporting screens for the people who run the business — order, inventory and payment views that stay readable as the numbers move.

Most internal tools are judged on the demo, when there are twelve rows of data. They're used on a Tuesday morning with four thousand. Those are different design problems, and only one of them matters.

What this is for

  • The spreadsheet that runs your business and now has six tabs, three people editing it, and a formula nobody understands
  • Order, inventory and payment views your team currently assembles by hand from two systems
  • Reporting screens so the people making decisions stop asking someone to export a CSV
  • Admin panels for a product you already have, where staff need to see and change things customers can't
  • Operations dashboards where something needs watching in close to real time

What this isn't

  • A BI platform — if you need self-serve analytics across the whole business, Metabase or Power BI will beat a custom build on price and features
  • A pretty chart page — if nobody makes a decision from it, it's a screensaver
  • An enterprise data warehouse — different discipline, different budget, different specialist

What actually makes an internal tool good

It has to answer a question someone asks daily

The failure mode isn't ugly — it's irrelevant. A dashboard showing eleven metrics nobody acts on gets checked twice and forgotten. Design starts with a sentence: every morning, [person] needs to know [thing] so they can [do something]. If you can't finish that sentence, the screen shouldn't exist yet.

So the first question isn't what data you have. It's what decision gets made, by whom, and how often.

It has to stay readable when the data grows

Twelve rows and four thousand rows are different products. Real volume needs pagination or virtualisation, indexes on the fields people filter by, and aggregation done at the database rather than shipped to the browser and summed in JavaScript.

That last one is the most common reason a tool that felt fast in month one takes eleven seconds by month eight.

Permissions decide who sees what

Internal doesn't mean unrestricted. A warehouse lead and a finance manager need different views of the same order, and the rule has to be enforced at the server rather than by hiding a menu item.

Real-time, only where it earns its keep

Live-updating numbers are the most requested feature and the least often needed. Worth it when someone is watching — an order queue during a sale, an operations screen. Not worth it on a monthly revenue report, where it adds complexity for no decision that changes.

What it costs

Internal tools vary more than any other work — a single reporting screen and a full operations panel are different projects.

Single dashboard or reporting screen

From specified price

Multi-screen admin panel with roles

From USD $2,500 (about NZ$4,200)

Added to an existing app

Quoted after I've looked at the codebase

Fixed price, agreed in writing before anything starts. What moves the number: number of user roles · how many systems the data comes from · real-time requirements · whether your data model already supports the questions you're asking (often it doesn't, and reshaping it is the real work).

Before you commission anything

Write the sentence

Every [day/week], [role] needs to know [X] so they can [Y]. One per screen. If a screen doesn't have one, cut it from the scope.

Check whether an off-the-shelf tool does it

Metabase, Retool and similar connect to a database and produce usable internal tools with no build. They fit badly when your logic is unusual, your permissions are specific, or the tool must live inside a product you already own. When they fit, they fit for a fraction of this, and I'd rather point you there than take the work.

How it works

  1. 1

    Free 30-minute call

    What decisions get made, by whom, from what data.

  2. 2

    Fixed quote

    Screens, roles, data sources, timeline, and exclusions.

  3. 3

    Data and permissions first

    The questions decide the schema; both are expensive to change later.

  4. 4

    Build

    With a link to follow progress.

  5. 5

    Launch and handover

    Code and accounts in your name, plus 30 days of fixes.

Why work with me

  • You talk to the developer who builds it, not an account manager
  • Fixed price agreed upfront — changes are quoted before they're built
  • You own everything — code, database, hosting, in your name from day one
  • Built for real data volume, not demo volume

The tradeoff:

I work remotely from Pakistan with clients in New Zealand and Cyprus. Lower cost and direct access — and no in-person meetings, plus a timezone gap. Internal tools often need close contact with staff who'll use them; if that has to happen in a room, hire locally.

FAQ

Questions before we start

From specified price for a single reporting screen; multi-screen admin panels with roles start at USD $2,500 (about NZ$4,200). What moves it: number of roles, how many systems the data comes from, and whether your existing data model can answer the questions you're asking.

Usually — if it's in a database or reachable through an API. The work is often less about the screens than about reshaping data stored for one purpose into something that answers a different question.

Quite possibly. Off-the-shelf tools are excellent when permissions are simple and logic is standard, and far cheaper than a build. Custom wins when the rules are specific, the tool must live inside an existing product, or it's used daily by people whose time is expensive.

Yes, using Socket.io where it's warranted — an order queue, an operations screen someone actually watches. On a monthly report it adds complexity for no decision that changes, and I'll say so.

Yes, and it should be enforced at the server, not by hiding menu items. Role-based access is the part of an internal tool most worth getting right early.

Often. I'd look at the codebase first and quote after — inherited code takes longer to work in than a clean start, and anyone quoting fixed without looking is guessing.

Related services

Dashboards often work best alongside custom applications. Some benefit from performance optimization.

Custom Web Applications

Data-driven apps with real roles and workflows

Speed & Core Web Vitals

Optimize if the dashboard feels slow with large data

Get a fixed quote

Tell me what your team needs to see and what they do with it. You'll get a realistic scope and fixed price before anything starts.

Get a fixed quote

See recent work · Custom applications