Building software for AEC firms starts with what a number means

Most of building Excede is not writing features. It is sitting with a firm's real data and deciding what each number means before anyone sees it on a screen.

My title is Forward Deployed Engineer. In practice I build the application, deliver it together with the firm that will use it, and make sure it's right. I run the audits, and I talk to the vendors whose systems we connect to. Much of what I've learned doing that is about numbers, not code.

The founders, Jonathan Sharp and Rafael Figueroa, are practicing engineers. They built Excede for their own MEP firm, Collectif Engineering, and that firm still runs on it. For development that means something plain. Every screen had a real user before it had a customer. If a report was wrong, someone who signs drawings noticed. Their firm sits in the platform like any other firm. It gets no special access to anyone else's data.

The firm already has its systems

No firm starts empty. Accounting lives in one tool. Hours live in another. Invoices, proposals, and a spreadsheet nobody wants to retire live somewhere else. We don't ask the firm to move. We connect to what it has and bring the data in. After that, Growth, Execution, and Finance all read from the same project.

The connection isn't the hard part. The hard part is that two systems name the same project differently. If the match is wrong, the hours land on the wrong job, and every number after that describes the wrong project. A lot of the work is matching that isn't exciting and has to be right.

Every firm books money its own way

Take the same cost at two firms and it can sit in two different places in the books. One firm counts payroll taxes as project labor. Another puts them in overhead. One firm treats contract labor as staff. Another treats it as a consultant. Both are reasonable. They push the net multiplier in opposite directions.

So the platform doesn't choose for the firm. Those choices are settings the firm owns. If a multiplier depends on a choice somebody made, the person reading it should be able to see that choice. Nobody trusts a number they can't trace back.

The month the work happened and the month it was billed

One decision explains a lot about how the product thinks. Hours stay in the month they were worked. That's the month utilization and project cost are counted in. Revenue goes in the month it was billed. When hours are written off, they don't get folded into some billed month where they would disappear. They stay visible as a loss.

That keeps realization honest. Otherwise the bad month looks fine and the problem shows up at closeout. That is exactly what the founders built this to stop.

A bug or a decision

When I find two ways a calculation could go, the first question is whether it's a bug or a decision. Some of them aren't bugs.

Say a firm has more than one legal entity. Someone filters to one entity that has no numbers of its own yet. Do you show the company total or nothing? The total looks complete and is wrong. Nothing is honest and looks broken. Code can't settle that. A principal can. So it goes to a person instead of getting quietly fixed.

Changing a number someone already trusts

Once a firm reads a number every week, changing how it's calculated is a big deal, even when the new way is more correct. So changes go in one firm at a time, behind a switch. We compare the old number with the new one on that firm's own data, so we can explain the change before the firm sees it. We also check the platform against the source system the firm already trusts. If they don't match, we find out why first.

A firm that wasn't ours

A firm we delivered to recently didn't work the way the founders' firm does. Its books are in QuickBooks. The founders' firm runs on Zoho, so that's where most of the platform was shaped first. They work in Google Workspace. The platform had been opening a Microsoft Teams channel for every new project.

We didn't ask them to change how they work. We adapted. A project in Excede can now be linked to a job in QuickBooks, so invoices they had already sent show up on the right project. A new project can open a Google Chat space instead of a Teams channel.

Before they logged in, we walked through the whole platform on data shaped exactly like theirs. A new firm doesn't have everything filled in yet. Their projects didn't have a project manager assigned. The screen that groups money by project manager simply left those projects out, so money they were owed showed as nothing outstanding. Nothing crashed. The money just wasn't on the screen.

We changed it. Money without an owner yet now shows up under Unassigned and counts in every total. Money shouldn't vanish because a field is empty.

What it adds up to

The software matters. What makes the product work is the time spent inside a firm learning how it actually keeps its books and runs its projects. The next firm will do something differently too, and the platform has to bend to that without bending the numbers.

Does that make sense? The short version is that we build the numbers with the firm, not for it.