The Problem
T-Bot worked—past tense feels premature since it still runs—but 'worked' captures something true.
Twisthink built it years ago for resource management. Track projects. Log time. Assign people. For a smaller team, sufficient.
Then they grew. And T-Bot's cracks widened into chasms.
Data lived in silos: TSheets for time tracking, QuickBooks for billing, Bamboo for HR, T-Bot for project management. None agreed. Finance spent hours weekly syncing manually. Ask three people about utilization, get three answers.
Fragmentation breeds distrust. When systems don't agree, people create shadow systems. Excel spreadsheets. Personal tracking methods. Each one a small rebellion against the official tools.
The commercial replacement cost $50K+ annually. So they asked: Rebuild, buy, or suffer?
What We Heard
This was a domain mapping and discovery engagement, so we worked with internal stakeholders rather than end users.
Project leads knew assignment logic. Finance knew billing rules. Team members knew time tracking pain. But nobody had the complete picture.
Stakeholders could describe symptoms—"it's clunky," "it doesn't work right," "we waste hours reconciling"—but couldn't articulate the structural problems.
The fragmentation was accepted as normal. People built workarounds—personal spreadsheets, manual reconciliation processes—instead of questioning why the tools didn't agree.
The Method
We didn't design screens. We didn't even commit to rebuilding.
We mapped the domain.
This is the part that surprises people. Six weeks of work, zero wireframes. Just objects, attributes, and relationships. Because before you decide what to build, you need to understand what exists.
Seven objects emerged:
PROJECT had 37 attributes. Thirty-seven. Project number, phase name, forecasted vs. actual costs, hours variance, system IDs for TSheets and QuickBooks, additional margins for T&M vs. Fixed Price, client relationships, team assignments. When you see 37 attributes on one object, you're probably conflating concepts. Or the domain is genuinely that messy. Usually both.
TEAM MEMBER had 26. Market rate adjusting yearly. Resource type with different workflows. Billable percentage targets varying by role.
TIME SHEET → TEAM MEMBER is a composition relationship—time sheets can't exist without an owner. Deletion cascades matter. Delete the person, what happens to their time entries?
CLIENT → PROJECT → EXPENSE — everything flows up for billing. That relationship chain is why Finance was doing manual reconciliation.
What looked simple—track time, manage projects—revealed a web of business rules nobody fully understood.
OOUX forced us to make the implicit explicit.
The Solution
Documentation completed in 6 weeks mapping the complete domain across seven objects.
37 attributes on PROJECT alone revealed the complexity hiding in "simple" resource management.
Relationships documented showing how TIME SHEETS flow through PROJECTS to CLIENTS for billing, explaining why Finance was doing manual reconciliation.
System-of-record designations clarifying which platform (TSheets, QuickBooks, Bamboo, T-Bot) was authoritative for which attributes.
Business rules made explicit—deletion cascades, composition relationships, billing flows—turning tribal knowledge into shared understanding.
A practical blueprint the team could act on, regardless of whether they rebuilt, bought, or optimized existing tools.
What Changed
Documentation completed in 6 weeks.
Stakeholders could finally articulate why T-Bot felt broken: "TIME SHEETS don't relate directly to CLIENTS, so Finance maps through PROJECTS manually."
That sentence! That's the value. Before the mapping work, people said "it's clunky" or "it doesn't work right." After, they could point to specific relationship gaps.
Conversations shifted from "add this button" to "how should this object relate to that one?"
Whether they rebuilt T-Bot? We never found out. The engagement ended, and I don't know what they decided. Sometimes the value is in the clarity, not the pixels.
Lessons for Others
First: Internal tools deserve external-tool thinking. Your team uses them more than clients use your product. They deserve the same care.
Second: Complexity is rarely where you expect it. 37 attributes suggests you're conflating concepts—or the domain is genuinely that messy. Usually both. Don't judge the number. Understand why it's there.
Third: Relationships are the system. A TEAM MEMBER is simple until you ask "which PROJECTS?" through "which TEAMS?" with "what TIME SHEETS?" The entities are easy. The connections are where the business logic lives.
Fourth: The map itself can be the product. Not every project needs to ship software. Sometimes understanding is the deliverable.
Fifth: Fragmentation breeds shadow systems. When official tools don't agree, people create personal workarounds. Those workarounds are a signal that your structure is broken.
Broader Implications
Internal tools are often treated as afterthoughts. Quick builds that "just need to work." But teams use them daily, and poor internal tools create compounding friction.
When commercial replacements cost $50K+ annually, the buy-vs-build decision gets strategic. But you can't make that decision without understanding what you actually need. Domain mapping de-risks the choice.
This pattern—multiple systems, fragmented data, manual reconciliation—appears everywhere. Not just in resource management. Any organization with legacy tools and organic growth faces this. The teams that map their domains before buying or building ship faster and choose better.
The End
Seven objects. Thirty-seven attributes on one. Zero lines of code.
Somewhere, someone at Twisthink is still reconciling timesheets across systems. Or maybe they rebuilt. Or maybe they bought something.
We'll never know. And that's fine.
The map exists. What they do with it is their choice.
But at least now when they argue about whether to rebuild, they're arguing about the right things.