This wasn't supposed to be a company.
An EPC company building highways and power grids needed software that could host its actual work. There wasn't any. So we built it.
scroll, slowlyIt was supposed to be a fix.
An EPC company building highways and power grids needed software that could host its actual work — obligation chains, dispute trails, vendor approvals, payment certifications, 532 record-shaped things that an Oracle module could not represent without three weeks of "customisation."
We tried to buy it. We tried to wrap it. We tried to integrate four products and call it a platform.
Then we stopped trying.
What follows is the longer version of why.
— Continue scrolling. The page is the argument.
Chapter 01 — THE PROBLEM: Two worlds.
No bridge.
Software has gone wrong in two opposite directions, and refused to meet in the middle.
The Fortress.
Enterprise systems were built for control. They assume the company is correct and the human is the variable to constrain. Workflows are dictated, not adapted.
It works, in the brutal sense that a fortress works. Nothing gets in. Nothing gets out. Nothing moves quickly.
- ExamplesSAP · Oracle · Workday
- Sold asgovernance
- Cost of changesix figures
- Velocityquarters
The Archipelago.
Modern SaaS was built for usability, and solved that problem brilliantly. Each tool, alone, is a pleasure to use.
Together, they are an archipelago. Documents on one island, conversations on another, files on a third. None of them know the others exist.
- ExamplesNotion · Linear · Slack
- Sold asdelight
- Cost of changelow — per island
- Velocitydays · per surface
Individuals outgrow their starter tools. Organisations are locked into rigid systems. The middle is missing.
Most companies in this gap pick a side. They build a better fortress, or a prettier island. We didn't pick a side. We started building the bridge.
— continue scrolling. the visual above resolves with the argument.
Chapter 02 — THE FORGE: Built where the pavement ended.
Most enterprise software is built by people who have never run an enterprise. Founders read McKinsey decks, interview a few CFOs, and ship modules for a workplace they have only studied from outside.
Fyboard was not built that way.
THE PARENT — RAJ CORPORATION LIMITED
RCL is a ₹4,500 crore EPC company in India. Highways. Power transmission lines. Concrete that has to hold for forty years. Steel that has to survive monsoons. Contracts whose obligation chains run thousands of pages, signed across a dozen counterparties, enforced over decades.
Real-world infrastructure does not let you fudge. A wrongly-routed approval is a stalled site. A misfiled invoice is a vendor with a lien on your equipment. A lost dispute trail is a court date.
When you build highways, precision is the only option. The same is true of the software that runs them.
WHAT WE TRIED FIRST
RCL paid SAP. We paid Oracle. We paid integrators to bridge SAP to Oracle. We paid a different set of integrators to bridge Oracle to whatever Microsoft was selling that year.
None of it survived contact with how an EPC company actually operates. Workflows that the consultants assured us were "industry-standard" were nothing of the kind. The systems modelled procurement as if every vendor were a generic supplier, ignoring that an EPC's vendors come with security deposits, retention amounts, performance bonds, payment certifications, and disputes that can run for years after the project closes.
We did not need software that worked for "most companies." We needed software that worked for the actual one.
532 TABLES
We started by mapping what we actually had. Not what the consultant deck said we should have — what the operations team kept in spreadsheets, in emails, in heads, in legal binders.
Five hundred and thirty-two tables. Each one a record-shaped thing the existing software could not represent without forcing the human to lie.
When you map a real business onto its actual schema, you stop building features. You start building the engines those features will eventually plug into.
Most platforms are built in a vacuum. This one was forged on a construction site.
— RCL is Fyboard's first user. It will not be the last. But it sets the bar.
Chapter 03 — THE ARCHITECTURE: Engines, not apps.
The standard SaaS approach is to ship apps. A contracts app. An HR app. A CRM. A project tracker. Each is a self-contained product with its own data, its own logic, its own way of representing a person, a record, a workflow.
Stitch enough of them together and you have a stack. Try to make the stack feel like a single system, and you have an integration team. Try to scale the integration team, and you have nothing — because the gaps multiply faster than the team grows.
Apps are surfaces. We don't build surfaces first. We build the engines that surfaces sit on.
FyBrain.
Intelligence layer.
Reads files. Extracts entities, clauses, amounts, dates. Knows the difference between a paragraph and a clause, between a price and a penalty. Local-first by default.
- Surfaceevery module
- Localitytenant-resident
- Outputstructured records
Workflow.
Orchestration layer.
Approvals, conditions, escalations, SLAs, audit trails. Stateful and recoverable. A failed step pauses cleanly; it does not roll the universe back to zero.
- Surfaceevery approval
- Statepause-resumable
- Auditfirst-class
FyDrive.
Files & documents.
Permissions, versions, lineage, share links. Files that carry structure. Tightly integrated with FyBrain so every file is understood the moment it arrives.
- Surfaceevery file
- Lineagepreserved
- Sharingcontract-bound
Apps. Stitched.
Each app has its own data, logic, comments, approvals. Stitch enough together and you have a stack. Try to unify it and you have an integration team. Try to scale that team and you have nothing — gaps multiply faster than headcount.
Engines. Shared.
Every module rides the same engines. The comment is the same comment. The approval is the same approval. The file is the same file. There is no duct tape because there is nothing to tape together.
MODULES ON TOP
AlphaCore for contract lifecycle. DataBoard for forms and structured data. People for HR. New modules — vendor management, finance close, project ops — cost an adapter, not a fork. Each module is a thin layer. The weight lives in the engines underneath.
When something improves in FyBrain, every module gets smarter. When Workflow learns a new condition type, every approval chain inherits it. When FyDrive ships a new permission shape, every file across every module respects it.
Engines are expensive. Surfaces are cheap. Build the expensive thing well, and the cheap thing scales for free.
WHY THIS MATTERS
Most B2B platforms market themselves as suites. Underneath, they are duct tape — separate apps with separate databases pretending to share a system. The duct tape is invisible until you try to use the platform across a real workflow, at which point you discover that the contract module's "comment" is a different thing from the document module's "comment," and neither knows about the conversation in chat.
Engine-first means the comment is the same comment, everywhere. The approval is the same approval. The user is the same user. The file is the same file. There is no duct tape because there is nothing to tape together.
— this is the architectural decision the entire company exists to defend.
Chapter 04 — THE SOLO: Why one engineer.
Why now.
The most-asked question about Fyboard is some version of: how is one person doing this? Two answers — one timeless, one era-specific.
Decision velocity.
The most-asked question about Fyboard is some version of: how is one person doing this?
The honest answer has two parts. One is about decision-making. The other is about 2026.
In a team of twenty, every architectural decision is a meeting. Every disagreement is a Slack thread. Every framework choice is a quarterly review. The work happens, but it happens through committee — and committees are biased toward consensus, which is biased toward the average idea, which is biased toward the kind of software you have already seen built.
Solo, every decision is an action. The cost of a wrong call is a weekend of rework, not a quarter of alignment. The cost of a right call is the work itself, no further negotiation required.
This is slow on features and fast on foundations. Which is exactly the trade we wanted.
The LLM era.
Five years ago, one person could not have built this. The bottleneck was not creativity or vision; it was the volume of unglamorous code that an enterprise platform requires. Schema migrations. CRUD endpoints. Form validators. Audit-trail plumbing. Test scaffolding. Tens of thousands of lines of work that is necessary, well-understood, and historically required headcount.
Modern language models do that work. Not perfectly — every line ships through a human review, every architectural choice is human, every engine boundary is human. But the labor of typing has stopped being the limit.
The bottleneck stopped being keystrokes. It is now taste — knowing what to build, what not to build, and which lines of an LLM's confident output are quietly broken.
WHAT SOLO DOES NOT MEAN
Solo does not mean alone. There is a small group of frontend collaborators, design reviewers, and early users at RCL whose work is visible in every commit. Solo means no committee. It means a single architect at the keyboard who can defend every line in the engines.
It also does not mean forever. Fyboard will hire when the engines are stable enough that new hands can extend them without re-deriving them. That moment is closer than it was last year. It is still not yet today.
— solo is the right choice now. it will not be the right choice for ever. we will know which is which when we get there.
Chapter 05 — THE BET: Twenty twenty-nine.
Every company should make at least one public bet that has a date attached.
Here is ours.
By the end of 2029, Fyboard will have replaced SAP at Raj Corporation Limited.
Replaced is the precise word. Not augmented. Not integrated with. Not running alongside as a satellite. The full ERP — finance, procurement, HR, project ops, document control — running on Fyboard's engines, with SAP decommissioned.
If we make it, we have evidence — not opinion — that an engine-first platform can carry the weight of an Indian infrastructure company at scale. That is a foundation to grow from.
If we miss it, we will say so. Plainly, on this page, with the post-mortem published. A bet is not a bet if you can quietly redefine it later.
— track the bet at this page. we will update the marker as the date approaches.
If this resonated, three doors are open.
Thanks for reading.