Context
Speed is the product. The tools weren't keeping up.
This company's business model is built on getting permits faster than anyone else. When McDonald's needs to open a new location, or when a major airport needs to expand a terminal, the building permit process involves dozens of local municipalities — each with their own requirements, timelines, and quirks. This company has the relationships and proprietary processes to navigate all of that faster than any competitor.
Their internal tooling had not kept pace. The platform their entire team relied on for day-to-day operations was a locally-installed Microsoft Access database, built in 2005 and patched ever since. No cloud connectivity. No real-time data. No mobile access. A UI that had never been redesigned.
The system was built to store data. Not to help the humans working inside it.
The Problem
Two rituals that defined — and constrained — the entire business
The weekly data sync
Because the software stored data locally, there was no way to share live information remotely. Every Monday morning, every team member came into the office and physically connected their machines to a local network to merge data and pull down the week's files.
- A permit approved on Wednesday wouldn't be universally known until the following Monday
- Remote or flexible work was structurally impossible for the entire team
- A sync issue on any machine meant working from stale data for a full week
- New hires faced weeks of onboarding just to navigate a system with no visual logic
- Across the whole team, the ritual consumed up to eight working hours per person each month — time spent managing the tool instead of doing the work.
The weekly billing review — a manual audit of the entire business
Every week, the company owner personally ran a full billing review — a gauntlet of manual steps, each one a product of a system with no validation or built-in trust:
- A pop-up surfaced every time entry staff had started but forgotten to close — each requiring a manual decision before proceeding
- He reviewed a dense table of every billable hour for the cycle — 1,000+ rows, $100,000+ in revenue — reading each line for errors
- He ran manual spell check on the "Service Performed" column, which flagged permit industry terminology as misspellings
- He ran a separate spell check pass on the expenses section
- He generated a PDF of all invoices and scrolled through it visually to verify each one before sending
- He manually backed up the database multiple times during this process — triggering a command-line terminal to confirm each backup
- There was no way to do ad hoc billing; they could only run billing in batches at the end of every month
He wasn't doing this because he wanted to. The system gave him no other choice.
Before — Legacy task and project view
The legacy system — a Microsoft Access database, circa 2005. No visual hierarchy. No prioritization model.
After — New project and task view
Three-panel layout: navigation, task list with priority + status, project detail in context
Before — Legacy Billing Review
Total hours and revenue manually reviewed every single week — one PDF.
After — New Billing Flow
Configure · Review · Export — one flow, built-in validation
My Role
End-to-end design, from workflow analysis to shipped product
I was the sole designer on this engagement, working directly with three engineers to design and build the replacement platform from the ground up. The stack was Elixir on the backend and React on the frontend — choices that directly informed what was possible on the design side, particularly around real-time data.
01
Workflow analysis
Understanding how permit specialists actually worked day-to-day — what information they needed when, and where the existing tool was creating failure.
02
Information architecture
Restructuring the data model and navigation to match the mental model of the work, not the underlying database schema.
03
Interaction & system design
Designing the task and status systems, project views, billing flow, and UI patterns that would scale as the platform grew.
04
Cross-functional collaboration
Partnering with engineering on cloud infrastructure decisions — the technical and design choices were deeply intertwined throughout.
Approach & Key Decisions
Four decisions that defined the redesign
1 — Infrastructure first: cloud as a design constraint, not just a technical one
The move to cloud fundamentally changed what the interface could do. Real-time data meant the system could show live status, surface updates as they happened, and allow simultaneous multi-user work without data conflicts. Every design decision was made with this in mind.
2 — Separating projects from tasks
In the legacy system, project-level tracking and individual task management were muddled together — specialists constantly had to parse which level of the work they were looking at. The redesigned system introduced a clean two-level hierarchy: the permit engagement as a whole, and the individual actions within it.
A constraint worth naming: Every decision was made against a backdrop of long-term users with fifteen years of muscle memory. The goal wasn't to impress them with something new. It was to build something better that felt immediately navigable on day one.
3 — Status as a first-class design element
In the old system, status was a field in a form. In the new system, status became the primary organizing principle of the entire interface.
- Every task and project had a clear, enforced status: active, blocked, in review, submitted, approved, closed
- The dashboard surfaced work by status — specialists arrived each morning seeing what needed attention, not a neutral list
- Blocked items were visually elevated — surfaced as requiring action, not buried in a list
4 — Redesigning billing from the ground up
The billing ritual was a symptom of a system with no trust built into it. The goal wasn't to replicate what the client was doing in a cleaner UI — it was to make the manual audit unnecessary by building validation into the workflow itself.
- Time entry validation built into the logging flow — errors caught at creation, not discovered during billing week
- Invoice generation became a single action, not a multi-step process involving backup rituals and PDF scrolling
- Enable the client to send ad hoc invoices for the first time, without having to wait for the monthly billing cycle
Outcomes
Two rituals eliminated. One team unblocked.
The most significant outcomes were structural — things the business simply could not do before, now possible by default.
Client estimated 15–20% increase in annual revenue to the platform. A direct result of the time and operational capacity the team recovered.
The weekly sync ritual was eliminated. The team moved from scheduled physical data merges to information that was always current for everyone, regardless of location.
The billing review went from hours to minutes. Multi-step manual verification — unlogged entries, spell checks, PDF scrolling, command-line backups — was replaced by a streamlined digital flow with validation built in.
Remote and flexible work became viable for the first time. A structural constraint the team had worked around for years was simply removed.
Onboarding time decreased. The new system's navigation and hierarchy matched how permit specialists actually thought about their work, reducing the learning curve significantly.
The platform established a foundation for future automation. For the first time, operational data was clean, structured, and accessible — opening the door to analytics and process automation that the old system never permitted.
What I'd do next
The platform we shipped was the foundation, not the ceiling. The natural next phase would have been operational analytics: permit throughput by municipality, average time-to-approval by client type, bottleneck identification. The team was now generating clean, structured, real-time data for the first time — the logical next step was turning it into operational intelligence.
