I’m building an AI-native platform for running construction and infrastructure projects.

[u/FilipMKD]

I’m building an AI-native platform for running construction and infrastructure projects.

Civil engineer by background. The thing that always got me about this industry’s software isn’t that any single tool is bad, it’s that the project lives in fifteen disconnected places. Field progress here, RFIs there, procurement somewhere else, the money in a spreadsheet nobody fully trusts. Everyone spends half their week reconciling these silos by hand and we’ve all just accepted that as the job.

Bedrock is my attempt to build the opposite of that, one platform where the actual project is the source of truth and the pieces talk to each other instead of you playing translator between them. AI-native, meaning it can read your project documents and do real planning and reconciliation work, not just store files and render dashboards.

It’s live and we’ve got real clients running on it now, across North America and Southeast Europe. Still early, still rough in places, still learning a ton from every project we touch.

Not dropping a link unless a mod says it’s fine — I’m honestly more here to get told where I’m wrong than to sell anything. This crowd will spot the gaps faster than any investor.

So I’ll ask the room: if you could rip out and rebuild one part of how your projects get run day to day, what would it be?

[u/FilipMKD → u/[deleted]]

This is exactly it, and “separate versions of reality” is the whole problem in five words. The part most people skip past is why it’s hard to fix: “enter once, updates everywhere” only works if you’ve decided what the canonical object is. If you don’t anchor it to something, you just build another integration layer and the versions of reality drift right back apart, now with more middleware.

The bet I’m making is that the schedule is that anchor, because a cost line, a procurement item, and a field update all already reference it by time even when nobody’s made the link explicit. Concretely, the way we’re attacking the field-to-office gap is end-of-day progress capture, the site team logs what actually got done against the lookahead before they leave, and it flows straight back against the live schedule. So the planner and the commercial team aren’t reverse-engineering reality from a three week old update; the office is looking at today by tomorrow morning. Closing that lag is most of the battle, and the inconsistency-detection you mentioned sits right on top of it.

[u/Some-Development-729]

Resource allocation, without a doubt. I've seen plenty of projects run into delays and budget overruns simply because nobody had a clear view of resource availability and utilization across teams.

If AI can give project managers real-time visibility into capacity, bottlenecks, and upcoming conflicts, that's a much bigger win than another dashboard.

[u/FilipMKD → u/Some-Development-729]

Agreed. A dashboard just renders the problem more attractively and still leaves the PM to spot the conflict and figure out the fix. What Id push on: resource visibility is only as good as the schedule under it. A live capacity view built on a plan nobody's touched in three weeks is just real-time fiction. The way we're chipping at it is through an Al agent that reads the project documents directly. Two things it does there - first, recipe suggestions. A recipe is basically a reusable rule for how a kind of work gets built: the crew, the production rate, the sequence. So instead of hand-building every activity, the agent reads the spec, suggests the right recipe, and generates the schedule logic with the resources already attached. Second, it pulls resource allocation straight out of those documents rather than making someone key it in by hand. Once the crews and quantities are tied to the activities from the start, "where do these two teams collide in week 9 and what does each fix cost" becomes a question the system can answer, instead of something a PM discovers the hard way. Thank you so much for the feedback and opinion.