Build or buy

Couldn't we just build this with AI?

It's the right question to ask. Here's the honest answer.

You could build the easy part this weekend. The part that makes the answers trustworthy — and keeps them that way — is a job that never ends. That's the part you'd own.

Lumopath gives your post-sales team trustworthy numbers on capacity, coverage, and account health — built from the activity already in your tools.

Why it's hard

Ask the same question twice.

An AI that calculates a number on the spot — hours per account, capacity, a retention rate — won't give you the same number when you ask again. That's fine for a chat. It's a problem when the number goes in a board deck, a headcount decision, or someone's performance review. Trustworthy numbers have to be computed the same way every time, stored, and then explained by the AI. Doing the math inside the model is the one thing you can't let it do — and rebuilding it as a real pipeline that does the same thing every time is the project.

Every number is computed the same way every time, stored, and versioned. The AI only explains it — it never does the math.

Start here

The AI is the easy 5%.

Pointing a smart model at your data is genuinely simple — a weekend, maybe an afternoon. But a model can only repeat what your data tells it. When the data is messy, incomplete, or means different things in different tools, the model hands you a confident answer that's wrong. Everything that makes the answer right lives around the AI — not inside it.

the model · a weekend
everything that makes it trustworthy · months, then forever

The small part is the model. The big part is the work that lets you trust it — and unlike the model, it doesn't stop once it's built.

A real example

The system said someone spent 7.5 hours on an account. It was really about 40 minutes.

Nothing was broken. The data honestly looked like 7.5 hours — until someone who knew the work said “that can't be right,” found out why, and corrected it. Then the same kind of error had to be checked in a hundred other places.

A model will never catch this. It doesn't know what forty minutes of real work feels like. People do — and getting every number to match reality is most of what the work actually is.

A model can read your data. It can't tell you when your data is wrong.

The dangerous failures are silent

It breaks in ways you won't see.

A build that fails loudly is the good case. The dangerous one looks fine and is quietly wrong — and you find out when it costs you a customer, a hire, or a number in a board meeting.

Looked fineWas wrong

A one-line timezone default silently blanked a whole metric for everyone west of Eastern time, every afternoon — no error, just “—”.

Looked fineWas wrong

A weekly briefing said a rep owned 191 accounts; the dashboard said 8. Two pieces of code counted differently.

Looked fineWas wrong

A data sync showed green while millions of updated rows silently sat behind a stuck checkpoint.

Looked fineWas wrong

“Meeting time” quietly counted days people were on vacation, because two code paths disagreed on what to exclude.

What you'd actually be signing up for

Three jobs that come with building it yourself.

01

Getting the data honest

Your information lives in nine or more tools that don't agree with each other. The same customer, ticket, or hour gets counted twice — or missed entirely. Untangling that, and keeping it untangled as your tools change, is constant work, not a one-time setup.

02

Agreeing what the numbers mean

What counts as an active customer? How do you measure whether you kept one? The answers feel obvious until your team disagrees — then the definitions change, and change again. Each change has to be re-applied across all your history so the numbers still line up.

03

Running it forever

A first version takes two or three of your best engineers a year — and then they can't leave. Tools change, definitions move, things break before the meeting that needed them.

The part nobody scopes

Building it means hosting everyone's private data yourself.

To produce these numbers, the system reads the whole company's messages, calendars, and HR records. Build it in-house and all of that raw data now lives in a system your team owns and secures — a standing privacy and legal exposure. Buy it and your team sees only finished, role-scoped metrics; the raw data stays isolated, under SOC 2 Type II.

The honest math

Even in the best case, it isn't close.

Assume your engineers are excellent and move fast. The comparison still doesn't hold up — because most of the cost was never the code.

Build it yourselfBuy Lumopath
Time to something usefulA year or moreA few weeks
Up-front costRoughly $500K+, plus 2–3 of your senior engineersA predictable subscription
Are the numbers right?You find out when a wrong one costs youAlready checked and corrected — with a year of history behind them
History on day oneNone — models start cold12 months reconstructed, definitions already tuned
Who keeps it running?Your team — indefinitelyWe do
Your best engineersStuck on internal toolingFree for the product your customers pay for

A programmatic-advertising company went from 0% to 100% of managers able to see where their team's time goes — in 14 weeks.

Don't take our word for it

Here's the actual build list. Decide for yourself.

We wrote down the real engineering work behind Lumopath — 96 jobs, boiled down, that a demo never shows you. Copy it, hand it to your team, and check off everything you've already built.

Open the build-it-yourself checklist

Objection FAQ

The questions you're right to ask.

Grant it completely. The year doesn't go to writing code. It goes to agreeing what each number means, matching them to reality, passing security review, and earning your team's trust in them — none of which code generation speeds up. (We use the same AI tools, which is part of how the product ships as fast as it does.)

Some you could — and most teams asking this already have a warehouse and still can't answer the real questions. A one-time query isn't a definition maintained identically every week, across tools that change and org charts that shift.

APIs existing isn't data being right. Even teams that buy a unified-integration API end up rebuilding connectors by hand when whole systems' data doesn't come through. Connecting the first tool is the easy part; keeping 143 of them honest as each changes on its own schedule is the job.

Your data is already exportable, so the build option never closes. Buying is the cheap way to keep it open. Building now spends the year and the headcount before you know the org will adopt it.

It's usually the reverse. In-house, raw messages and inboxes for the whole company sit with your own team to secure. With us, only derived metrics ever leave the raw systems — under SOC 2 Type II, with audited deletion.

A v1 that quietly computes wrong numbers is worse than none — wrong capacity numbers move real headcount. The cheap version is exactly the one people stop trusting, and trust is the thing you're actually buying.

Forwarding this internally?

Send the right person the right part.

The decision

Buying keeps every door open. Building closes this year.

Your data stays yours and exportable — if you ever decide to build later, that option is still there. Building now means spending your best people, and a year you can't get back, to recreate something that already exists, already works, and already understands your business.

Book a demo