All entries

In the earlier note on Ascent's internal operating system, Repo appeared as a single module: the centralised master-data layer beneath Velocity, Stack and Kanban. This note zooms into that layer.

Over the past few weeks Repo has grown from a clean clients-and-products database into the system of record that keeps five legal entities, their accounting, and every downstream system speaking the same language. It is live and in production, with the newer capabilities being rolled out in phases.

The approach is unchanged from the rest of the ecosystem. Repo is built by consultants who understand the operational reality first, with AI accelerating execution under a human-in-the-loop model. It is API-first, so each system around it can evolve on its own lifecycle while consuming a consistent version of the truth.

[A] The master-data core

Repo holds the records that everything else refers to: clients, and the products and solutions Ascent delivers.

Key capabilities

• Client master records with full contact, tax and address detail, each under a stable code.
• Product and solution catalogue with built-in version control, so a product's commercial terms can change over time without losing history.
• Multiple contact persons per client, each with a defined role.
• Bulk onboarding through Zoho Books CSV imports, mapping existing contacts and items into Repo without rekeying.

Because every client and product carries a stable code, downstream systems can reference a record for its lifetime, independent of any single accounting system's internal identifiers.

[B] One repository, five sets of books

Ascent operates through five legal entities: ASWPL, ABPL, AFTLLP, NAQTLLP and ACTSPL. Each keeps its own Zoho Books organisation. Rather than maintain client and product lists five times over, Repo is the one place data is entered, and it pushes each client and product into all five books.

Key capabilities

• Push-based synchronisation from Repo to every connected Zoho Books entity.
• Per-entity linkage, so the same client or product is tracked correctly even though it carries a different identifier in each set of books.
• Credentials for each entity managed centrally and encrypted at rest.
• On-demand sync to a single entity or to all of them, alongside a scheduled background sync.

The synchronisation is built for the messiness of real accounting data. Repo matches an existing Zoho contact by GSTIN, then email, then name before it ever creates a new one, so connecting a new entity's books links to what is already there instead of duplicating it. It resolves the correct GST state code for place of supply, and it adapts automatically to entities that are not GST-registered, learning and omitting the fields those books do not accept.

[C] Data integrity by design

A single source of truth is only useful if it stays clean.

Key capabilities

• Duplicate detection and merge by GSTIN, or by name and email, with a guided manual merge for the harder cases.
• A customers-only master, with vendor records kept out of the operational data set.
• Contact classification into Business and Tech.

The Business and Tech distinction carries real meaning downstream. Business contacts are the people who belong on financial correspondence, so Repo syncs them into Zoho Books as the customer's contact persons, where they become the default recipients on proforma invoices, tax invoices and payment receipts. Both Business and Tech contacts flow to the delivery systems, which need the technical points of contact as well.

[D] The API layer

Repo earns the title of single source of truth by making its data easy for other systems to consume.

Key capabilities

• Read-only REST API secured with revocable API keys.
• A published, machine-readable OpenAPI specification alongside human documentation, so a downstream team can generate a client in minutes.
• Pagination, filtering and stable identifiers throughout.
• Per-entity Zoho references exposed on every client and product.

That last point closes an important loop. When a delivery system such as Ascent Stack or Ascent Kanban needs to raise an invoice in a particular entity's books, Repo hands it the exact Zoho contact and item identifiers for that entity. The invoice is then created fully linked to the accounting master, so tax, ledger accounts and HSN or SAC codes populate automatically rather than being copied across by hand.

Built to be trusted

Because Repo now holds the keys to five accounting systems, its own security matters. Entity credentials are encrypted at rest, and each connection uses least-privilege access scoped only to what the synchronisation needs. The master data itself is edited in one governed place, rather than being spread thinly across systems.

Why this matters

Repo is deliberately unglamorous. It has no dashboard to sell and no workflow to demonstrate. What it provides is quieter and more valuable: the confidence that a client, a product, a tax number or a price means the same thing in sales, in accounting, in delivery and in support.

A business does not run on features. It runs on shared, trustworthy facts. The job of a master-data system is to make those facts identical everywhere, and then to get out of the way.

This is one layer of a larger, API-first operating system being built from inside a live consulting business. The upcoming notes will follow the satellite systems as they connect to Repo, and the lessons that emerge from letting operational understanding, rather than software convention, shape the design.

Over the past four to five weeks, we have been building the next generation of Ascent’s internal operating system. Every capability described here is already live and in production, with additional satellite systems being connected in phases.

The architecture is being shaped by consultants with over a decade of business process experience, with minimal dependence on traditional software development or UI teams. It is an AI-built system with a human-in-the-loop (HITL) approach, where operational understanding drives the design and AI accelerates execution.

Each module is being developed as an independent system, connected through APIs so that every product can evolve on its own lifecycle while remaining part of a unified ecosystem.

[A] Ascent Velocity

For a B2B business, the real sales funnel is not forms or campaigns, but interactions: calls, meetings, discussions and referrals.

Every interaction is recorded in Ascent Velocity. When an interaction matures into a business requirement, a lead can be created with a single click. Leads may also enter directly through sales outreach, events or partner introductions.

Velocity is the first operational entry point into the Ascent ecosystem, taking a prospect through qualification, nurturing and conversion.

Key capabilities

• Interaction-to-lead conversion
• Direct lead capture from sales, events and partners
• Automated lead progression workflows
• Real-time engagement tracking through email integration

Velocity integrates with Zoho Mail so that all outbound communication is stored in the sales team’s mailbox, while inbound client replies automatically update the relevant lead record.

Once a lead is marked Converted, the workflow moves to business operations. Velocity integrates with Zoho Books to create either a Proforma Invoice or a Tax Invoice, which is then sent directly to the client.

The next phase connects invoicing with delivery activation:

• payment confirmed in Zoho Books,
• client environment created or updated in Ascent Stack,
• project automatically created or updated in Ascent Kanban.

[B] Ascent Stack

Ascent Stack is the organisation’s technology asset repository.

It maintains:

• solutions delivered to clients,
• third-party integrations,
• subscription and validity information,
• access credentials and environment references.

Each solution is mapped to a client, with client master data managed centrally through Ascent Repo.

[C] Ascent Kanban

Ascent Kanban combines project management, effort tracking and support operations in a single execution layer.

For delivery projects

• timesheet-based effort tracking,
• project cost visibility,
• human-capital utilisation monitoring.

For support and maintenance

• ticket-based operational tracking,
• support cost accounting,
• billable ad-hoc support management.

Kanban also integrates with Zoho Books, ensuring that all support-related billing flows through a single accounting and compliance system.

A dedicated Zoho Mail integration automatically converts support emails into tickets and merges subsequent replies into the existing ticket thread, eliminating manual ticket logging.

[D] Ascent Repo

Ascent Repo is the centralised master-data layer and single source of truth for the ecosystem.

It manages:

• client master records,
• product and solution catalogues,
• product version control,
• relationships between clients, products, projects and operational systems.

Repo synchronises client and product information with Zoho Books, ensuring consistency across commercial, operational and support workflows.

Why this matters

This initiative is not about building another ERP. It is about designing systems around how a business actually operates.

The early outcome reinforces a simple belief:

The most effective enterprise systems are not the ones with the most features. They are the ones that most accurately reflect how an organisation thinks, collaborates, delivers and grows.

This is only the first chapter. The upcoming notes will cover the satellite systems being connected to this architecture and the broader lessons emerging from building an AI-assisted, API-first operating system from within a live consulting business.

The ability to Learn, Unlearn and Re-learn every 3-5 yrs - has always been a key to success for most software engineering professionals. In other words, learn (a new and promising tech) in six months, become a pro over the next 6-12 months and maximize earnings over the next ~3 yrs. Repeat this for 3-4 times during the working age and one achieves compounding returns.

AI has disrupted this theory in ways most people, including software professionals, have failed to understand.
This is a completely new chapter in the Capital vs. Labour textbooks.

There is an acute shortage of tech sales professionals / consultants and no one is talking about it.

Most software engineers spend years before they get into sales (client-facing) roles and are responsible for PnL management. The smarter ones among the fresh graduates will compress this timeline to months, instead of years.

The more I use AI, the more I realise that great AI outputs depend less on AI itself and more on two human qualities: (1) clarity of thought and (2) the ability to articulate it well.

This is how the tech landscape has changed...

Some of the best software developers I've worked with - (1) speak average English, (2) think in their native language, (3) but have fantastic clarity in translating business requirements to code.

These developers are now competing with AI-empowered software developers who can articulate requirements and communicate effectively in English.

Every time I attend a technology expo in India or the UAE, I notice a pattern.

Indian stalls are predominantly software.
Chinese stalls are predominantly hardware.

And within India's software identity, core software product development still doesn't receive the recognition it deserves.

---

The journey began in the early 1990s with software services. Indian engineers solving technology problems for businesses in the West.

Then came the BPO, KPO, and ITES wave. While not software development in the traditional sense, it became part of the broader IT narrative. So much so that government policies often treated IT and ITES as a single category.

The next wave was start-ups.

Many built products for global markets. Others built for India using global capital. Much of the software innovation during this period involved adapting proven models to Indian realities.

E-commerce. Aggregation platforms. Marketplaces.

Important businesses, certainly.
But did we build enough foundational technology of our own?

There are notable exceptions. Companies such as Mastek, KPIT and Infosys have developed industry-specific products and platforms, often drawing from decades of services experience.

Yet, for a country with our engineering talent and scale, it feels like we should have covered far more ground over the last three decades.

---

The good news is that we have an opportunity to accelerate.

AI can help us clear technical debt, compress development cycles, and pursue solutions that may have previously been uneconomical to build.

At the same time, we need a stronger hardware ecosystem. Software leadership without hardware capability leaves too much value on the table.

Perhaps the next chapter of India's technology story should not be about services, outsourcing, or adaptation.

Perhaps it should be about building.

Many startup founders have spent years inside large organisations before starting out on their own.

So when they build their companies, they consciously avoid the things they disliked most: layers of approvals, slow decisions, and processes that get in the way of execution.

In the early days, that works brilliantly.

But growth changes the equation.

As teams expand, customers increase, and responsibilities multiply, startups inevitably need systems and processes. The challenge is no longer whether to introduce them, but how to do so without slowing down innovation.

The founders who seem to navigate this transition best understand that processes shouldn't create bureaucracy. They should create clarity, accountability, and the ability to scale.

Interestingly, we've seen a very similar pattern in SMEs once they cross certain growth milestones. Different businesses, different contexts - but often the same underlying questions:

• How do you build an organisation that is structured enough to scale, yet agile enough to keep evolving?
• At what stage did formal systems and processes become necessary in your organisation?
• And what worked - or didn't work - during that transition?

No tool - machine or software - can fix a broken process.

We’ve been solving the wrong problem.

Transactional systems remove redundancy - for efficiency.
Data warehouses add it back - for insight.

Two systems. Two truths.
Neither complete.

AI doesn’t bridge this gap.
It exposes it.

If data can’t move from transaction to insight to action,
it’s not a data problem.

It’s an architecture problem.