Why generic project software breaks for architecture practices

Most project management software is built for a generic notion of "a project" — a bucket of tasks with due dates, assigned to people, tracked to completion. That model works reasonably well for a software team shipping a feature, or a marketing team running a campaign. It breaks the moment you try to run an architecture practice through it, because a practice isn't managing projects in the generic sense — it's managing a chain of contractual, billable, and regulatory commitments that a task board was never designed to represent.

A fee proposal is not a task list

When an architecture firm proposes a fee, that number isn't arbitrary — it's derived from a COA (Council of Architecture) fee scale, tied to the project's construction cost slab, broken down by work stage: concept, preliminary design, working drawings, tender, construction supervision. Each stage unlocks a percentage of the total fee, payable against a specific deliverable, not against elapsed time.

Generic project software has no concept of a "work stage that unlocks billing." You end up bolting this on with custom fields, or worse, tracking it in a separate spreadsheet that drifts out of sync with whatever the task board says is actually done. The fee proposal, the phase structure, and the invoice should be three views onto the same record — not three documents you reconcile by hand every billing cycle.

GST and TDS aren't a finance-team problem to solve later

Professional fees in India carry GST at 18%, and depending on the client, TDS deduction under Section 194J. A software tool that treats invoicing as "type in a number, mark it paid" is going to cost your accountant hours every month reconstructing the actual liability — and it's going to cost you accuracy, since architecture billing has enough real complexity (advance adjustments, retention against a phase, debit notes for scope changes) that manual reconciliation is where errors creep in.

This isn't a nice-to-have. It's the difference between software that understands what an architecture practice actually does, and software that was built for something else and patched to sort of fit.

One record, not a folder per app

The deeper issue is architectural (in the software sense, not the professional one): when your fee proposal lives in one tool, your invoicing lives in another, and your project tracking lives in a third, nothing actually references anything else. An invoice doesn't know which proposal it came from. A task doesn't know which phase it belongs to. Every link between them is a human remembering to keep two systems in sync — and eventually, someone doesn't.

A practice runs cleaner when a client, a project, a fee proposal, and every invoice against it sit on one connected record — not because it's tidier, but because "which phase is this invoice for" stops being a question anyone has to answer manually. The system already knows.

AORMS is built specifically for this — COA fee scales, phase-wise billing gates, and GST/TDS on professional fees are native to the model, not custom fields bolted onto a generic project tool. See how it works →