How Architect Darani uses automation without losing professional accountability

Every architect and quantity surveyor registered in Kenya operates under the Board of Registration of Architects and Quantity Surveyors (BORAQS). Registration carries legal obligations: the professional is personally accountable for the documents they sign, the advice they give, and the work they certify. This accountability cannot be delegated to software, no matter how sophisticated.

At the same time, clients expect speed. A developer considering a plot acquisition wants a feasibility opinion in hours, not weeks. A contractor submitting a payment application wants it certified promptly. A project falling behind programme needs decisions made quickly, with all relevant information at hand.

The tension is real: professional accountability requires careful review and documented reasoning, which takes time. Client expectations demand rapid turnaround. The question is not whether to choose speed or accountability — it is how to design a practice where automation handles the time-consuming data work so the professional can focus their time on the review and sign-off that only they can give.

This article explains how Architect Darani's practice resolves this tension, using REDM automation tools while maintaining full BORAQS-compliant professional accountability at every stage.

Construction projects generate enormous volumes of documentation: feasibility reports, design briefs, bills of quantities, tender documents, contract particulars, payment certificates, variation assessments, practical completion certificates. Each document carries professional weight and, in many cases, legal consequence.

Automation can accelerate document production significantly. A feasibility report template that pulls project data — plot area, zoning classification, benchmark construction rates, statutory fee estimates — directly from the project file eliminates hours of manual data entry and transcription. A payment certificate that reads the contract sum, previous payments, and current valuation from the same data model eliminates arithmetic errors and reconciliation time.

The key principle in Architect Darani's practice is that automation produces the draft; the professional reviews and signs the final document. The feasibility report is generated from the project data model, but the registered architect reviews the assumptions, checks that the zoning classification is current, verifies that the benchmark rates are appropriate for the specific site conditions, and signs the report personally. The automation saved hours of data entry. The professional accountability sits exactly where BORAQS requires it: with the registered professional.

This pattern — automate the draft, review the output, sign the final — applies to every document type in the practice. The audit trail in ERPNext records who generated the draft, who reviewed it, what changes were made during review, and who approved the final version. If a question arises later about why a particular assumption was made, the trail shows the chain of professional decisions.

The REDM feasibility wizard is designed to produce a documented, reviewable set of assumptions before any design work begins. When a developer submits a plot for a project check, the system pulls parcel data, zoning classification, and local construction benchmarks. It generates a preliminary feasibility output that includes: estimated gross floor area based on plot coverage and plot ratio constraints, preliminary construction cost based on use type and specification level, statutory fee estimates based on published county schedules, and a projected programme based on project type and scale.

Every assumption in the output is documented and traceable. The zoning classification is linked to the relevant county plan or regulation. The construction cost benchmark cites the source data and the date it was last updated. The statutory fee estimate references the published fee schedule and the calculation method.

This documentation serves two purposes. First, it allows the professional to review the assumptions efficiently — the architect or QS does not need to reconstruct the logic from scratch, only to verify that each assumption is appropriate for the specific project. Second, it provides the professional with a defensible basis for their signed opinion. If a client or authority questions the feasibility numbers, the professional can show exactly which assumptions were made and on what basis.

The alternative — a feasibility opinion prepared from scratch without documented assumptions — is faster to produce in isolation but harder to review, harder to defend, and harder to update when conditions change. The automated, documented approach produces a better professional work product, not just a faster one.

Professional accountability requires more than signed documents. It requires the ability to reconstruct why a decision was made, who made it, and on what information. When a project runs into difficulty — a cost overrun, a programme delay, a dispute over a variation — the ability to trace decisions back to their source is what separates a managed problem from an unmanaged crisis.

Architect Darani uses ERPNext as the central project record system. Every project communication, every document version, every consultant appointment, every payment certificate, and every variation instruction is recorded in the project file with timestamps and user attribution. When the architect reviews and signs a document, that review is logged. When a QS assesses a variation, the assessment reasoning is captured alongside the decision.

This is not the same as 'the software made the decision.' The software recorded the decision and its basis. The professional made the decision. The distinction is critical for BORAQS compliance: the registered professional remains the decision-maker; the system provides the evidence trail that supports professional accountability.

For developers managing multiple projects, the ERPNext audit trail provides something additional: consistency across projects. If the same type of variation arises on two different projects, the developer can review how it was handled previously and ensure consistent treatment. The institutional memory sits in the system, not in individual professionals' recollections.

A Kenyan development project involves multiple registered professionals: the architect (registered with BORAQS), the quantity surveyor (registered with BORAQS), the structural engineer (registered with the Engineers Board of Kenya), the MEP engineer, and potentially specialist consultants for geotechnical investigation, environmental impact assessment, and fire engineering.

Each professional operates within their own scope of registration and carries their own professional accountability. Automation tools that cross professional boundaries must respect these scopes. A cost benchmark generated by the system is not a QS opinion until a registered QS reviews and signs it. A structural design option flagged by the feasibility tool is not an engineering recommendation until the structural engineer evaluates it for the specific site conditions.

Architect Darani's practice manages this through clearly defined handoff points. The feasibility wizard generates preliminary outputs across all disciplines. Each output is routed to the relevant registered professional for review. The professional may accept, adjust, or reject the automated output based on their professional judgment. Only after that review does the output become a professional deliverable.

This model preserves professional accountability while eliminating the inefficiency of professionals spending time on data aggregation and arithmetic that automation handles faster and more consistently. The professionals' time is concentrated on the parts of the work that require their training and judgment.

A developer commissioning professional services in 2026 should expect more than a traditional practice that happens to use email instead of a typewriter. Technology should demonstrably improve the speed of routine outputs, the quality of documentation, and the consistency of decision-making across projects.

Specifically, clients should expect: preliminary feasibility outputs with documented assumptions within days rather than weeks; cost plans and estimates that reference current benchmarks rather than historical rates adjusted by memory; variation assessments that cross-reference contract documents automatically before the QS evaluates the claim; payment certification that reconciles automatically with the contract sum and previous certificates; and a project audit trail that allows any decision to be traced to its basis and its author.

At the same time, clients should expect that automation does not mean abdication. The registered professional should still sign every document personally. The assumptions in every output should be reviewable and challengeable. The professional's judgment on risk, market conditions, and project-specific factors should remain the final authority, not the automated output.

Architect Darani's practice is built on this model: technology handles the data work; professionals handle the judgment calls; the audit trail proves who did what. It is a model designed for BORAQS compliance, not despite it.