LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
Secure AI virtual data rooms10 bus. days
To start
From a signed scope
100%
Code and CMS
Yours from the first commit
Every sprint
A working build
On a preview URL, not a deck
Fixed scope
Agreed before we build
No surprise change orders
What we build
What we build for architecture firms
Most firms come to us for the website. The conversation that follows it is usually about the systems the firm runs behind the scenes — because a portfolio that generates leads is only useful if what happens after the inquiry is also working.
Firm website and project portfolio
The public-facing site, built to carry large renders and photography without becoming the slowest thing a prospective client experiences, and structured so each project reads as a case study — the brief, the constraint, the outcome — rather than a gallery with a caption.
Client and project portals
A scoped view for an active client to see drawings, approvals, and milestone status without a phone call, and a scoped view for consultants and contractors to upload what they owe you. The hard part is permissions, not the interface — each party should see only what's theirs.
Proposal and fee-tracking tools
Turning an RFP or a fee proposal into a document your team can produce quickly and consistently, with the underlying numbers tracked somewhere more durable than the email thread it was negotiated in.
Document and drawing workflow
Version control and approval routing for drawing sets and specifications, built to match how your team actually reviews and releases documents rather than a generic file-sharing folder that loses track of which version is current.
Pipeline and pursuit tracking
A lightweight system for tracking active pursuits, RFP deadlines, and win/loss history — the thing most firms currently run as a shared spreadsheet that one person maintains and everyone else half-trusts.
Accessibility for public and civic work
Section 508 and WCAG compliance for firms that pursue public-sector or institutional work, where an inaccessible site or portal isn't just a UX gap — it can be a disqualifying issue in procurement.
The public site
The website is a portfolio, not a brochure
A prospective client evaluating an architecture firm is judging the work first and the words second, which changes what a good site actually optimizes for compared to a typical business website.
Image weight is the real performance problem
Renders and project photography are large by nature, and a portfolio site that ignores that loads slowly on exactly the connections a client is likely to be on — a phone, on-site, checking your work before a meeting. Responsive image pipelines and real lazy-loading aren't optional polish here; they're the difference between a site that gets browsed and one that gets abandoned on the first project page.
Each project is a case study, not a caption
The brief, the site constraint, the decision that mattered, and the result — structured consistently across projects — tells a prospective client more than a wall of un-annotated renders ever will. This is also the content a non-technical staff member should be able to add without calling a developer every time a project wraps.
Mobile is often the primary device, not a secondary one
A client walking a site with you, or a consultant reviewing a portfolio between meetings, is very often doing it on a phone. Designing mobile-first for an image-heavy portfolio is a harder constraint than it sounds, and it's the one legacy templated sites in this space skip most often.
The contact and inquiry flow is the actual conversion point
All the portfolio work in the world doesn't matter if the path from "I like this firm's work" to "I've reached someone" is a generic contact form that goes to an inbox nobody checks promptly. That flow should route to the right person and set expectations for response time — a small piece of the build that has an outsized effect on whether an inquiry becomes a client.
A CMS your team actually uses
If adding a finished project to the site requires a developer, it happens rarely and the site goes stale. The right CMS choice lets a marketing coordinator or a principal publish a new project themselves, with the image pipeline and layout handled automatically rather than left to whoever uploaded the photos.
What it costs
Architecture firm software engagements
What moves a quote is less about page count and more about asset volume — how many high-resolution renders and photos the site carries — and how many practice-management systems a portal or workflow tool needs to stay in sync with.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Firm website and portfolio rebuild | Fixed scope | 6 – 12 weeks | A new public site, image pipeline, and CMS your team can publish to, built around project case studies rather than a template. |
| Client or project portal | Fixed scope | 6 – 10 weeks | A scoped portal for clients, consultants, or contractors — drawing access, approvals, and milestone status, with permissions matched to who should see what. |
| Practice-management integration | Fixed scope | 4 – 8 weeks | Connecting your site or internal tools to Deltek, BQE Core, Newforma, or a similar system your practice already runs, so data doesn't have to be entered twice. |
| Pipeline and proposal tracking | Fixed scope | 4 – 6 weeks | A lightweight system to replace the pursuit-tracking spreadsheet, with fee-proposal generation built in. |
| Ongoing maintenance retainer | Ongoing retainer | Ongoing | Hosting, security updates, and content and feature support after launch, sized to how actively the site and portal keep changing. |
Ranges assume US-based senior engineers and include a real image and asset pipeline rather than treating it as an afterthought. A quote well under these bands is often missing that pipeline — and the gap shows up later as a site that loads slowly on exactly the renders it exists to showcase.
Integrations
Integrating with what your practice already runs
Very few architecture firms want a second system to maintain. The honest goal of most of this work is connecting to what you already use, not replacing it.
Deltek Vantagepoint and Ajera
Project financials, time tracking, and resourcing usually live here already. A client portal or dashboard we build reads from these systems rather than duplicating project status somewhere it can drift out of sync.
BQE Core
Billing, time, and project accounting for firms that run BQE — integration work here is typically about surfacing project status or invoicing data in a client-facing view without giving a client direct access to the accounting system itself.
Newforma and document management
Where drawing sets and project records live for many mid-size and larger practices. A custom portal built on top of it, rather than instead of it, keeps your team from re-learning where the source of truth actually is.
Revit and BIM exports
Embedding a lightweight model viewer or exporting renders and sheet sets for a client-facing portal, without asking clients to open the full modeling software to see anything.
When a plugin beats a custom build
Sometimes the honest recommendation is an existing plugin or a configuration change inside a system you already run, rather than a custom integration. We'll say so when it's genuinely the faster, cheaper path to the same result, and scope the custom work for the part those tools actually can't do.
Accounting and billing systems
QuickBooks or a similar general ledger, connected so invoicing and project financials don't have to be re-entered by hand between your practice-management system and your books.
Scoping
What decides scope and timeline
Four factors move an architecture-firm engagement more than anything else, and they're worth naming up front rather than discovering mid-project.
How much of the portfolio is being migrated versus rebuilt
Reworking image assets and rewriting case-study content for dozens of existing projects takes longer than the site build itself in many cases. Scope this honestly at the start rather than treating content migration as a footnote.
How many systems a portal has to stay in sync with
A portal that reads from one practice-management system is a much smaller build than one that has to reconcile data across three, especially when those systems don't agree with each other about the same project's status.
Whether public-sector accessibility requirements apply
Section 508 or state-level accessibility requirements change how a site and any client portal are built from the first component, not as a review pass at the end. Firms that pursue public or institutional work should flag this before design starts.
Single office versus multi-office and multi-brand
A firm with several offices, or several sub-brands under one practice, often needs shared content infrastructure with office-specific presentation — closer to the multi-brand portal work we do elsewhere than a single-office site.
Related
Related services
Other work architecture firms commonly pair with a site or portal build.
Questions
Common questions from architecture firms
What teams ask before a first call.
Both, and most firms end up wanting both once the conversation starts. The public portfolio site is usually the first ask, but the practice-management and project-workflow tools behind it are where a lot of the actual return sits — because that's where a spreadsheet or an email thread is currently standing in for real software.
Yes. Most architecture-firm engagements involve connecting to at least one of these — reading project status or financials into a client-facing portal, or syncing document metadata rather than maintaining it twice. We scope the integration around your existing system rather than asking you to replace it.
Yes. We build the image and asset pipeline a render- and photography-heavy portfolio needs to load quickly, and where it's useful, embed a lightweight model viewer or export sheet sets for a client portal — without requiring clients to open Revit or similar modeling software themselves.
We build to WCAG standards by default and to Section 508 or a specific state requirement when a firm's pipeline includes public-sector or institutional work. This gets flagged and designed for at the start of a project, not audited in afterward, because retrofitting accessibility into an existing interface is close to a rebuild.
Yes. The site, its CMS, and the codebase live in your organization's accounts from the first commit, with us added as collaborators. That's the only arrangement that doesn't leave you dependent on us to publish a new project or make a small edit later.
Most firm website and portfolio rebuilds run six to twelve weeks, depending heavily on how much existing project content is being migrated and rewritten versus built fresh. A scoping call gives a real number once we've seen how many projects and how much existing content are involved.
Yes — this is a common request. We build shared content infrastructure with office-specific presentation, similar in spirit to how a multi-brand company runs several public-facing sites from one underlying platform, so your team isn't maintaining separate systems per office.
Hosting, security updates, and dependency maintenance are typically bundled into an ongoing retainer sized to how actively your site and any portals keep changing. Content updates through the CMS don't require us at all once your team is trained on it — that's part of the point of building it that way.