Internal tools
A custom internal tool is a purpose-built application that replaces the spreadsheet, shared inbox, or paper process a team has outgrown: an admin dashboard, an estimating tool, a client and project tracker, a reporting surface only the right people can open. I build these as fixed-scope projects on Next.js and Postgres/Supabase for small businesses and nonprofits around Lock Haven, Williamsport, State College, and central Pennsylvania, and remotely anywhere else.
The clearest example is the one I use myself. tdarby.com carries a contracting back office I built for my own licensed PA home-improvement business (PA HIC #PA2199962): clients, projects, photo galleries, a document builder for estimates, invoices, and proposals, and tokenized share links that let a homeowner open a document without needing an account. I write real estimates in it. It is also what I'd adapt from for anyone who needs estimating software built around the way their own crew quotes work.
Most internal tools fail on permissions rather than features. Volunteer Clinton County, which I co-founded and developed, keeps every table in a dedicated Postgres schema under row-level security, with a four-level membership hierarchy and a submission status machine the database itself enforces, so neither the app nor the API can bypass moderation. GrantCue layers role-based permissions and multi-level approval workflows over the same foundation. That is the pattern I bring down to a five-person office.
Scope is fixed by project and settled before code starts. The first pass writes down the workflow as it actually runs, names every user and what each one is allowed to do, and cuts the first release to the part that earns its keep. Cost moves with the number of distinct roles, how much legacy data has to be migrated and cleaned, and how many outside systems the tool has to talk to. You get the number with the proposal.
Handoff is part of the build. Your staff get an admin surface for the things that change often, documentation written for the person who will actually use it, and a stack with no exotic parts: Next.js, React, Postgres on Supabase, deployed on Vercel. Nothing about the system requires me to stay on retainer, and if you hand it to another developer later, the code is conventional enough to pick up.
What you get
- A working internal application deployed to hosting accounts in your name, with separate staging and production environments
- Role-aware access: named roles, per-role permissions, and row-level security enforced in Postgres
- An admin dashboard for the daily work, with search, filters, bulk actions, and the reporting views your team asks for by name
- Migration of the existing spreadsheet or database, including the cleanup pass nobody wants to do by hand
- Document generation and tokenized share links where an outside party needs to see something without an account
- Email notifications and scheduled jobs for the reminders currently living in one person's head
- Written handoff documentation, a walkthrough for whoever administers it, and the repository and credentials transferred to you
- A post-launch correction pass for the issues that only surface once staff use it every day
Shipped work behind this
- GrantCue — A multi-tenant platform that ingests the federal Grants.gov catalog plus eleven state portals on a schedule, then layers AI discovery, fit-scoring, and proposal drafting over a full team pipeline.
- Volunteer Clinton County — A civic platform I co-founded and developed, where local organizations post volunteer opportunities, events, and donation drives and residents sign up and log hours — on a hardened, security-first data model.
Start a project
Bring me the practical version.
Tell me what you're trying to build or improve and what's already in place — I'll reply with a clear next step.