Todos Build: an environment of construction apps, not another all-or-nothing suite
Founding designer on a construction management software venture. I originated the product's core strategy — individually selectable, interoperable apps rather than a monolithic suite — and designed all 19 applications from discovery to developer-ready specification. It went into daily use by more than 400 people.
The problem
A construction company buying software today has a bad choice in front of them. The major platforms — Procore and its peers — are sold as suites: you buy the whole thing, you pay for the whole thing, and you use maybe a third of it. For a regional contractor, that means paying enterprise prices for modules nobody in the building will ever open.
The alternative is worse. Buy point solutions for the two or three things you actually need, and now your estimating data does not talk to your project data, your RFIs live in email, and someone is retyping numbers between systems every week.
The idea
My contribution at the strategic level was to propose that we stop thinking of the product as a suite at all, and design it as an environment — a set of construction apps a customer can select individually, that still share data and workflow because they were built to live in the same place.
A company that only wants Bid-Leveling and Drawings buys Bid-Leveling and Drawings. If they add Submittals two years later, it drops into the environment already knowing about their projects, their directory, and their documents. No migration, no integration project, no paying for nineteen apps to get two.
That decision shaped everything downstream. It meant every app had to be designed to stand alone and to compose — which is a much harder design problem than building modules inside a suite, and it is the reason the information architecture work came before any of the screens.
Worth noting
This is the second time I have designed a product around this idea. In 2016 I proposed the same integrated-environment concept for supply chain compliance at Azzule Systems, in a completely different industry. Both times the insight was the same: the customer does not want a bigger platform, they want the pieces they use to stop being separate.
How each app got designed
Nineteen applications, one repeatable process. For every app:
- Audit what exists. I evaluated the tools already on the market for that specific job, and the tools our own people were using instead — which was usually a spreadsheet, a PDF, and a habit.
- Interview the person who owns the problem. Long conversations with the subject-matter owner about how the job is actually done, on-site and off, and precisely where existing products fail them. Not what features they want. Where the current thing breaks.
- Find the failure point before drawing anything. Almost every app had one specific moment where the existing workflow fell apart. That moment became the thing the app was designed around.
- Design the whole surface in Figma. Every screen, every state, every click-level interaction, specified so a developer could build it without guessing at intent.
- Iterate in the open. I sat between the product owner and a remote developer, translating domain expertise into use cases and written UX direction through structured review cycles, and adjusting the design as the build revealed what the conversations had missed.
The 19 applications
Bid-Leveling, Estimating, RFIs, Submittals, Drawings, Takeoff, Specifications, Documents, Projects, Directory, Team Management, Asset Management, Daily Logs, Receipts & Invoices, Project Photos, Budget, Contracts, Change Orders, and T&M Tickets — plus the environment that houses them and lets them share data.
They serve genuinely different people. An estimator at a desk with two monitors and a superintendent on a phone in the wind are not the same user, and designing for both inside one system was the recurring constraint.
What happened
Todos Build launched in house and reached daily use by more than 100 internal users spanning every function in the business — estimating, project management, accounting and HR, superintendents, and field crews — plus over 300 external users: project owners following live project information.
In March 2026 the parent company paused funding for its software division and the team's positions were paused with it. The product had already been proven in production, across five job functions, in the hardest possible test environment: the people who would tell you immediately if it made their day worse.
What I would tell you in an interview
The design work I am proudest of here is not a screen. It is that a company with no software product, no product team, and no design function shipped nineteen working applications to four hundred people — because someone sat down with the estimator and asked him to explain, slowly, what he actually does all day.