
A global engineering firm with thousands of employees needed a more reliable way to plan project time and capacity across teams, departments, and locations. Over time, resource planning had spread across disconnected spreadsheets and legacy web apps, each shaped around local needs rather than using shared organizational standards.
Employees could not easily see their own allocations. Project leaders lacked confidence in capacity forecasts. Administrators spent their time reconciling inconsistent records instead of making planning decisions. The problem was not a single broken process. It was years of tolerated fragmentation.
There were no specs, no mockups, no documented workflows. That was the surface problem. The deeper one was that different parts of the organization had different mental models of what resource planning should look like.
Requirements had to be discovered, not gathered. That meant the first challenge was not a technical one.
.webp)

With no existing specs, Six Feet Up's engineering team ran short design-build-demo cycles, surfacing requirements through visual mockups rather than written documentation. Those mockups were reviewed regularly with two audiences at once: business stakeholders and the employees expected to use the system every day.
That combination mattered. Stakeholders emphasized breadth of functionality. Day-to-day users prioritized speed, visibility, and ease of navigation. Those differences produced useful tension. Rather than debating requirements abstractly, the team could test assumptions against concrete workflows and real reactions.
Initial mockups focused on comprehensive feature sets, but feedback quickly revealed that certain core functionalities mattered more than others. Navigation was simplified. Overview dashboards became central once users repeatedly showed how much they relied on them. Features that seemed essential were deprioritized when they added complexity without enough value.
By the final demo sessions, the nature of feedback had shifted. Early sessions challenged core workflows and exposed gaps in understanding. Later ones shifted toward refinement, usability, and edge cases. The progression was evidence that the new resource planning application was becoming something users could trust.
Django provided the backend foundation. Docker Compose kept the development environment stable across iterations, a practical necessity while requirements were still being discovered. Azure DevOps handled code development, CI pipelines, and issue management throughout.
The application was also designed to fit the organization's existing internal tech stack and delivered automated, role-specific email digests with reminders and action items to employees and project leaders on a recurring schedule.
On the frontend, the team built with HTMX, JavaScript, and CSS, applying HTMX as extensively as possible to reduce reliance on custom JavaScript.
HTMX does a good job of handling server-driven interactivity like refreshing allocations, submitting updates, and loading dashboards. But this application pushed further. Bulk time entry, drag-and-drop scheduling, and dynamic filtering tested its limits. Where HTMX fell short, the team documented the constraints rather than building around them, giving future phases a concrete starting point.
Tables presented a separate challenge. They were not a secondary component in this application. They were the primary daily interaction surface, which made off-the-shelf libraries a poor fit. Most conflicted with the HTMX-driven update model and would have constrained key workflows, so the team built the table layer from scratch. It added scope, but the result fit the application rather than fought it.
.webp)
.webp)
.webp)
The new application replaced more than a decade of disconnected spreadsheets with a single resource planning tool that the entire organization relies on.
It previously took 30 minutes per person to complete resource allocations, and now it takes just 5 minutes. That’s six times faster. Across 400 employees, that recovers an estimated 160 hours per week.
Those who lived with the old spreadsheets now enjoy:
For complex internal platforms, the hardest problem is often not technical. A disciplined dual-audience approach surfaces what organizations actually need before the wrong thing gets built. If fragmented data is slowing your team down, let’s talk.




Geospatial Analysis from 30 Minutes to Seconds
US-based distribution company

Unlocking Value from Raw Time Series Signals
Healthcare technology startup