Before we build a product, we understand the practice. BdOS is the diagnostic methodology that maps how your operation actually runs — its revenue logic, capacity model, decision flows, and operational gaps. Everything GB59 builds is specified through BdOS first.
BdOS is not software you buy. It is a structured diagnostic engagement through which GB59 maps how your practice operates — end to end, from lead to delivery to invoice to collection — and produces a specification for the operating system your practice actually needs.
A structured diagnostic engagement. A methodology for understanding how a professional practice operates at the system level — revenue, capacity, process, and decision-making — not just at the surface of "what software do you use."
BdOS asks deeper questions: where does revenue leak? Where is capacity wasted? Where do decisions happen without information? What processes are held together by one person's institutional memory? What breaks when you try to scale?
The output is a Business OS specification — a precise map of what your practice needs to run on a proper operating system.
BdOS is not a consultancy report that goes into a drawer. It is not a generic business review. It is not a technology audit. It is not a strategy deck with generic recommendations.
BdOS is not done by questionnaire. It involves direct engagement with the practice — with the principals, the team, and the actual flow of work — over a structured engagement period.
The output of BdOS is always actionable: either you implement the specification through a GB59 sector OS, or you have a blueprint you can act on independently.
Every professional practice — regardless of sector — can be understood through four diagnostic domains. BdOS maps all four, and the intersections between them are where the most critical insights live.
How the practice earns money, and where it loses it. Fee structures, billing cycles, collection efficiency, scope creep exposure, retainer vs. project revenue balance, and the gap between what is billed and what is collected. Most practices are surprised by how much revenue disappears between delivery and collection.
How the practice converts its people and time into delivered work. Utilisation rates, bottlenecks, handoff points, where work pools and where it accelerates, which processes depend on a single person, and what the actual throughput ceiling of the practice is at its current configuration.
Where information lives, how decisions get made, and what the practice is blind to. Most practices are rich in output and poor in operational information — they produce excellent work but can't tell you their current WIP value, their effective hourly rate, or their true project profitability at any given moment.
What breaks first when the practice grows. Every practice has structural constraints that prevent scaling — not lack of work or talent, but operational limits. BdOS identifies these constraints before they become crises: the processes that don't scale, the systems that break at volume, the decisions that can't be delegated without proper infrastructure.
A BdOS engagement runs over four to six weeks. It is structured, bounded, and always produces a specific output — the OS specification for your practice.
We begin with a principals' session — understanding the practice's history, current state, goals, and pain points from the people who run it. This session shapes the diagnostic focus and defines the scope of the engagement. Duration: 1–2 days.
We go deep into the practice's actual operations — reviewing financial records, project files, process flows, team structures, and tool usage. We shadow workflows, interview team members, and map how work actually moves through the practice versus how principals believe it moves. Duration: 2–3 weeks.
The diagnostic findings are structured into an OS specification — a precise definition of the operating system your practice needs. This covers the modules required, the data flows between them, the reporting the practice needs, and the implementation sequencing. Duration: 1 week.
The Business OS specification is presented to principals with detailed explanation of every finding and recommendation. If your sector has an existing GB59 OS product (ARCHLOOP for architecture, BUILDLOOP for construction), implementation begins immediately. If not, you have a blueprint. Duration: 1–2 days plus onboarding.
Every GB59 sector OS — ARCHLOOP, BUILDLOOP, and every product that follows — was specified through BdOS. We ran BdOS engagements across Indian architecture practices before a single line of ARCHLOOP was written. The product is the codification of what BdOS found. This is why ARCHLOOP feels like it was built for how architecture practices actually work — because it was.
When you engage with BdOS as a practice, you are accessing the same diagnostic rigour that built our products. The output either maps to an existing GB59 OS, or it becomes the specification for what we build next.
See how BdOS shaped ARCHLOOP →You run a professional practice — architecture, construction, legal, clinical, creative, or property — with 5 to 50 people, and you are the principal or managing partner.
You feel like the practice is capable of more than it delivers, but you can't quite see where the constraint is. You know something is wrong but you don't have the data to pinpoint it.
You are willing to open the practice's actual operations — financial records, project files, workflow — to a structured diagnostic process. BdOS requires access, not just answers to questionnaires.
You want to scale, professionalise, or systematise the practice — not just solve a single problem.
You are looking for a quick audit, a report with generic recommendations, or a technology evaluation. BdOS is a deep engagement, not a surface review.
You are unwilling to share actual operational and financial data. BdOS works from real information, not sanitised summaries.
You need a solution in weeks rather than a proper diagnosis followed by a proper implementation. If you need something faster, start with ARCHLOOP directly — if you run an architecture practice, it is built on enough accumulated BdOS insight to be immediately useful without a prior engagement.
Tell us about your practice. We'll assess whether a BdOS engagement is the right starting point, or whether an existing sector OS is a faster path to the same outcome.