In partnership with

Learn AI in 5 minutes a day

This is the easiest way for a busy person wanting to learn AI in as little time as possible:

1. Sign up for The Rundown AI newsletter

2. They send you 5-minute email updates on the latest AI news and how to use it

3. You learn how to become 2x more productive by leveraging AI

Sign up to start learning.

Bridging the Gap: Why Data Science Projects Feel So Different from Architecture Projects

This week, I want to take a step back from the technical details of ML, AI, and data science in AEC to talk about project-focused data science—how these projects unfold in practice and why they often feel so different from traditional architecture workflows.

In my day-to-day work, alongside leading AI research, I’m involved in several client-facing projects. One recurring challenge is the fundamental differences between architecture projects and software or data-driven projects—differences that often lead to friction when setting expectations, defining success, or managing timelines.

Broadly, these differences boil down to four key areas:

1. Open-Ended Goals – The fluid nature of software deliverables compared to the well-defined outcomes in architecture.

2. Dependence on External Inputs – Why data science projects often can’t start immediately and why unknowns emerge mid-project.

3. The Curse of the Final 20% – How moving from a working MVP to a polished, production-ready tool takes far longer than expected.

4. A Dynamic Deliverable – Why software and AI projects continue evolving long after launch, unlike traditional architectural designs.

1. Open-Ended Goals: Defining "Done" is Tricky

In architecture, the deliverable is well-defined from the outset:

• A building that includes the required spaces,

• Passes code reviews,

• And is constructible within budget and site constraints.

While there is room for design iteration, the end goal is relatively clear— documents describing a tangible, physical structure.

In contrast, software and data science projects vary dramatically in scope and complexity. The final product could be:

• A simple analysis script used internally,

• A predictive model integrated into existing tools,

• Or a full-stack application with live data pipelines, real-time monitoring, and an intuitive user interface.

Small changes in deliverable expectations can have massive impacts on timelines. It's the difference between delivering a quick sketch versus delivering a full set of construction documents, specifications, and permit-ready drawings.

Bridging the Gap:

• Defining project goals as early as possible is crucial, but they should also remain flexible to account for new insights.

• Encourage clients to prioritize impact over perfection—a well-targeted MVP can be more valuable than a fully polished but bloated system.

2. Dependence on External Inputs: You Don’t Know What You Don’t Know

Unlike architecture, where teams can typically jump into design on day one, software and data projects often can’t truly begin until all the necessary data is available, cleaned, and structured.

Why this causes delays:

• Data quality is unpredictable. Missing, inconsistent, or biased data can derail early assumptions.

• Data access isn’t always immediate. Permissions, integrations, and security approvals can take time.

• Understanding the data takes time. Just because data exists doesn’t mean it’s useful for the problem at hand.

A huge portion of any data-driven project is spent in the data-wrangling phase—cleaning, structuring, and transforming raw information into something usable. This step is largely invisible to non-technical stakeholders, who might assume that modeling and insights begin immediately.

Bridging the Gap:

• Set clear expectations upfront: "We can’t predict the timeline until we assess the data."

• Separate the project into data exploration vs. model development—treating them as distinct phases helps manage expectations.

• Build early proof-of-concept prototypes to demonstrate progress before full deployment.

3. The Curse of the Final 20%: The 80/20 Trap

In many software projects, moving from a rough, usable MVP to a polished, robust application feels like it should only take 20% more effort—but in reality, it takes far longer than anticipated.

Why?

• Scaling and reliability take time. A quick prototype that works on a small dataset might break at scale.

• User experience (UX) matters. Making an application intuitive and user-friendly is a huge effort.

• Performance bottlenecks appear late. Issues like slow query times or unstable APIs may not surface until real users interact with the system.

• Edge cases emerge. The more a system is tested, the more unexpected failure modes are discovered.

This is often called the 80/20 rule of software development—the first 80% of the project is relatively quick, but the last 20% (polishing, debugging, deployment) can take more than double or triple the time. Something to think about is that small start-ups usually raise a few tens of thousands to develop an MVP, but they might need to raise a few million to develop their first market-ready product. With this in mind - it should be made clear the cost of polished software - even on the cheap side it is closer to $1M than it is to $10K.

Bridging the Gap:

• Make it clear that an MVP is not the same as a production-ready tool.

• Encourage phased rollouts—start with a beta version before committing to a fully polished system.

• Set realistic expectations: "The last 20% is where the real work begins."

4. A Dynamic Deliverable: Software Isn’t Static

Most architecture projects end with a set of documents that don’t require much ongoing support after the building is completed. Once constructed, a building largely remains unchanged, aside from minor maintenance and renovations.

Software and AI projects, however, don’t end at deployment. They continue evolving long after launch.

Why?

• AI models degrade over time. As real-world conditions change, a model trained on past data may become less accurate.

• Data ingestion continues: Tools developed on top of changing data sets need systems that continue to process this data into is usable form for the application.

• Software needs updates and maintenance. Security patches, bug fixes, and user-driven improvements are constant.

• User needs shift. As people interact with the system, new feature requests and use cases emerge.

Many AEC clients assume that software is like a completed building—once built, it’s "done." In reality, it’s a constantly evolving system.

Bridging the Gap:

• Emphasize ongoing monitoring and maintenance as part of the deliverable.

• Build tools with future adaptability in mind. Hardcoded assumptions lead to technical debt.

• Frame AI models as dynamic assets that require periodic retraining, not one-time solutions.

Key Takeaways: Lessons for AEC Data Science Teams

1. Define success early, but allow flexibility. Open-ended goals require continuous realignment.

2. Communicate the data exploration phase. "We don’t know how long this will take until we see the data."

3. Prepare for the 80/20 challenge. Moving from MVP to production is harder than it seems.

4. Set expectations around long-term support. AI and software are evolving, not static.

Closing Thoughts: A New Way to Build

Traditional architecture and software/data projects operate on fundamentally different assumptions. Architecture projects follow a structured, sequential process, leading to a static end product. In contrast, software and data projects are iterative, flexible, and continuously evolving—adapting to new requirements, data, and user needs.

To help AEC teams develop stronger intuition around software development, it may be useful to think about it more like construction rather than architectural design:

• You don’t know what you don’t know.
  Just as unforeseen site conditions (bad soil, hidden pipes) impact construction, unknowns in data quality and accessibility can drastically change software project timelines.

• Delays in sourcing materials (data) are out of your control.
  If a supplier is late with materials, construction slows down. Likewise, if data is missing, messy, or siloed, software progress stalls. Timelines need to remain flexible to accommodate these dependencies.

• Handovers are complicated and important.
  Construction projects require a smooth transition from contractor to facility management. Similarly, software and AI projects need clear ownership, documentation, and training for long-term usability and sustainability.

• Long-term management is key.
  A completed building requires maintenance—HVAC, security, repairs. Software is no different—it needs updates, monitoring, and adaptation over time to remain useful and effective.

By bridging these gaps—aligning expectations, clarifying unknowns, and planning for long-term evolution—AEC professionals and data teams can collaborate more effectively, ultimately creating solutions that integrate the best of both worlds.

What are your experiences navigating these differences? Let’s discuss. 🚀