When did running an architectural firm become more about managing software than managing projects?

It’s a question I started asking myself after returning to architectural practice following two years working in the technology industry. I came back with a different perspective, a renewed appreciation for what technology could accomplish, and a genuine excitement about the rapid development of artificial intelligence.

I wanted to bring some of that innovation into the architectural office. Not because I believed technology could replace the experience and judgment of architects, but because I saw an opportunity to make our work easier. To reduce the administrative burden, improve communication, and give people more time to concentrate on the work they were actually trained to do.

What I discovered was that we already had plenty of software.

In fact, we had so much of it that managing the software was becoming part of the problem.

When Every Problem Has Its Own Platform

The architectural industry has no shortage of excellent technology. There are sophisticated tools for drawing production, project management, construction administration, financial reporting, scheduling, document control, and communication. Many of these platforms are genuinely impressive, and each has contributed something valuable to the way we work.

The problem isn’t necessarily the quality of the software. It’s the way everything fits together. Or, more accurately, the way it often doesn’t.

In our office, we had different systems for different responsibilities. Project information lived in one place, financial information somewhere else, and staff resources in another. Human resources information might be buried in a shared drive, while contact information was spread between email, spreadsheets, and individual employees.

Every platform had its own purpose, its own login, its own subscription, and its own way of organizing information.

And yet, despite all these tools, I still found myself asking colleagues the simplest questions.

Do you have Jim’s phone number? Where is the latest drawing set? Who is available to work on this project next week? Has that consultant responded? Where did we save the meeting minutes?

These aren’t particularly difficult questions. But when the information isn’t readily available, finding an answer requires interrupting somebody else.

A two-minute question can easily become fifteen or thirty minutes of interrupted work. Someone stops what they’re doing, searches through their files, responds to the question, and then has to find their concentration again.

Multiply that across an entire office, across dozens of projects, and across a full year.

The cost isn’t always visible on a financial statement, but the lost time is real.

The Price of Progress

I remember when the tools of our profession were considerably simpler. We worked with pencils, tracing paper, drawing boards, and eventually computer-aided drafting. Software was something you purchased, installed, and used for years. You upgraded when there was a compelling reason to do so.

Then came building information modelling, more sophisticated collaboration tools, cloud platforms, and subscription-based software.

Each advancement brought tremendous possibilities. I wouldn’t suggest going backwards. The ability to coordinate complex buildings digitally, collaborate across disciplines, and access project information remotely has fundamentally changed what we can accomplish.

But somewhere along the way, the economics changed too.

Instead of purchasing a few essential tools, architectural firms began accumulating subscriptions. A platform for this responsibility, another for that one, and another to solve a problem the previous two couldn’t address.

Individually, each subscription might seem reasonable. Collectively, they become a significant operating expense.

What concerned me most was the timing.

Architectural firms are under constant pressure to remain competitive. We pursue projects against other qualified firms, negotiate fees, manage staffing costs, and work to maintain profitability in an industry where project schedules and client expectations rarely become less demanding.

When competition becomes particularly intense, fees can come under pressure. Yet the cost of delivering the work doesn’t necessarily decrease with them. Salaries, insurance, technology, professional development, and office operations continue to demand investment.

Software is supposed to make us more efficient. But if we keep purchasing another platform to solve another isolated problem, at what point does the cost of our tools begin to undermine the efficiency we’re trying to achieve?

I started to wonder whether we were approaching the problem backwards.

Good Processes Shouldn’t Depend on Perfect Behaviour

There’s another challenge that anyone who has worked in an architectural office will recognize.

You can develop an excellent process. You can create a carefully structured spreadsheet, a well-organized folder hierarchy, or a Word template that captures exactly the information your team needs. You can spend hours refining it until it works beautifully.

Then someone else starts using it.

They save a second version. They change the formatting. They create their own copy because they prefer a slightly different approach. Someone forgets to update a field, or information gets recorded in an email rather than the shared document.

None of this necessarily happens because people are careless. Most of the time, they’re simply trying to get their work done.

But over time, small deviations create larger inconsistencies. Information becomes fragmented, and the process that was supposed to make things easier begins requiring more effort to maintain.

I’ve seen how frustrating that can become, particularly when multiple people are working on the same project.

The more I thought about it, the more I realized that good processes shouldn’t depend on everyone remembering every step.

The system itself should make the right process easier to follow.

Architecture Doesn’t Happen in Isolated Phases

One of my biggest frustrations with the software available to our industry was how often it focused on a single part of the project.

Some platforms were developed primarily around the contractor’s responsibilities. Others concentrated on construction administration, project scheduling, or financial management. Still others provided general business tools that architectural firms had to adapt to their particular needs.

But architects don’t work in one isolated phase.

Our involvement often begins long before a project is awarded. We identify opportunities, develop relationships, prepare proposals, establish fees, and assemble project teams. Once commissioned, we move through design, consultant coordination, approvals, tendering, construction, and ultimately closeout.

Information created in one phase has a direct relationship to what happens in the next.

A commitment made during a proposal may influence staffing months later. A decision during design may become an important clarification during tender. A drawing revision may affect construction costs. A field review observation may need to be carried forward through several reports before it is finally resolved.

These aren’t separate activities. They’re connected parts of the same project.

Yet we frequently manage them as though they’re independent.

Every transition becomes another opportunity for information to be copied, re-entered, misunderstood, or lost.

I kept coming back to one question: why were we building our workflows around the limitations of individual software platforms instead of building software around the way architectural projects actually unfold?

That question became the foundation of Project Arc.

One Project. Every Phase.

The idea behind Project Arc is straightforward: create one connected environment that supports the project from the earliest opportunity through to the final walkthrough.

Imagine receiving a request for proposal and recording that opportunity in your firm’s system. The client information, relationships, potential fees, and project history are already connected. As the opportunity develops, you can understand how it fits into the firm’s workload and future commitments.

When the project is awarded, that information doesn’t disappear into an archived proposal folder. It becomes part of the project record.

During design, the team can coordinate tasks, milestones, drawings, markups, and responsibilities within the same environment. Rather than asking someone to manually update a separate tracking spreadsheet, project activity contributes to a clearer understanding of progress and resources.

As the drawings develop, review tools can help identify coordination questions and potential omissions before major submissions. The intent isn’t to replace professional judgment, but to support it by bringing relevant information forward when it matters.

When the project moves into tendering, questions, responses, addenda, and communication remain connected to the project. The team isn’t starting over with another collection of spreadsheets and email folders.

And when construction begins, the architect, contractor, consultants, and owner can work from appropriate shared information while maintaining the responsibilities and controls specific to their roles.

RFIs, shop drawings, field reviews, changes, and outstanding items become part of a continuing project record rather than another isolated database.

That’s the vision.

Not simply fewer places to log in, but fewer opportunities for information to become disconnected.

Project Arc brings project schedules, team responsibilities, and milestones into one shared view.

Bringing Everyone onto the Same Page

Although Project Arc began with my experience as an architect, it quickly became clear that the challenge extended beyond architectural firms.

Contractors have their own responsibilities, deadlines, documentation, and financial pressures. Owners need visibility into decisions, budgets, progress, and the long-term operation of their buildings.

Each participant approaches the same project from a different perspective.

An architect may be concerned about design intent and contractual compliance. A contractor is coordinating trades, materials, labour, and construction sequencing. An owner is making decisions that affect cost, operations, and the people who will ultimately occupy the building.

All three may be working diligently, but that doesn’t guarantee they’re working from the same understanding.

Project Arc is being developed with tailored experiences for architects, contractors, and owners, connected through a common project environment. The objective is not to make everyone use identical tools. It’s to allow each participant to do their work while keeping the appropriate information aligned.

That distinction matters.

Better communication doesn’t necessarily mean more emails, more meetings, or more notifications. Sometimes it means giving people access to the information they need without requiring them to ask for it.

And sometimes it means making sure a decision made today is still visible to the person who needs it six months from now.

The Phase We Always Struggle to Finish

There’s one part of project delivery that deserves particular attention: closeout.

I often think about how similar it is to working on your own house.

You might spend months completing a renovation. The difficult work is finished, the rooms are usable, and everything looks almost complete. But there’s still that last piece of trim to install, a few nail holes to fill, or a small detail that needs attention.

For some reason, those final tasks can take longer to finish than you ever expected.

Construction projects have their own version of this problem, except the consequences are considerably greater.

Outstanding deficiencies, operations and maintenance manuals, warranties, record drawings, final inspections, and contractual documentation all need to be coordinated. Responsibility for individual items can become unclear, particularly as project teams begin shifting their attention to new work.

A project can be substantially complete while still requiring significant effort to finish properly.

I wanted Project Arc to treat closeout as an essential part of the project rather than an afterthought.

If outstanding items have been tracked throughout construction, if responsibilities are clear, and if documentation has been organized as the work progresses, closeout becomes a continuation of the process rather than an entirely new administrative exercise.

The final few percent of a project shouldn’t require reconstructing everything that happened during the previous ninety-five.

Building Knowledge Without Creating More Work

One of the most exciting possibilities behind Project Arc is what happens when project information remains connected over time.

Throughout a project, we make thousands of small decisions. We respond to questions, review drawings, record observations, coordinate consultants, and document changes.

Collectively, those activities tell the story of a building.

Historically, much of that knowledge has remained buried in separate documents and email conversations. We know the information exists, but finding it can be difficult, particularly when the person who originally dealt with an issue is no longer involved.

I believe artificial intelligence has the potential to change that relationship.

Rather than asking staff to spend more time entering information into another system, I want Project Arc to develop useful project context through the work people are already doing.

A drawing review, a tender clarification, or an RFI response should contribute to the project’s knowledge. Over time, that connected information could help teams locate decisions, identify unresolved questions, and understand how the project reached its current state.

This is the longer-term ambition behind Arc Intelligence.

It is not about allowing software to make professional decisions on behalf of architects. Accountability, judgment, and professional responsibility remain with the people delivering the project.

It’s about giving those people better access to the information they need to make informed decisions.

And importantly, firms shouldn’t have to begin at the proposal stage to benefit. They should be able to bring an existing project into Arc during design, tendering, or construction and begin building that connected record from wherever they are.

Why I Decided to Build It

I didn’t set out to create another software company simply because I thought the architectural industry needed another product.

Quite the opposite.

I was tired of seeing firms purchase more and more software while still struggling with the same fundamental problems.

I was frustrated by the amount of time spent searching for information, maintaining disconnected systems, and repeating administrative tasks that should have been straightforward.

And I was concerned that the rising cost of technology was placing additional pressure on a profession already working hard to remain financially sustainable.

But I also saw an opportunity.

Architecture is a collaborative profession. We rely on the expertise of people with different responsibilities, different perspectives, and different ways of working. Delivering a successful building requires those contributions to come together in a coordinated way.

Our technology should support that collaboration, not make it more complicated.

That’s why I started Project Arc.

Not because I believe software can eliminate the complexity of architecture. It can’t, and it shouldn’t pretend to. Buildings are complicated because people, places, budgets, regulations, and aspirations are complicated.

But unnecessary fragmentation is a different kind of complexity. It’s something we can improve.

I want Project Arc to help architectural firms spend less time managing their systems and more time managing their projects. I want contractors and owners to have better visibility into the work that matters to them. And I want the knowledge developed throughout a project to remain accessible rather than disappearing into another folder when the job is complete.

We’ve spent decades developing better ways to design buildings. I think it’s time we gave equal attention to how we deliver them.

If you were starting your firm from scratch tomorrow, knowing what you know today, would you really run it the way you’re running it now?