A global education groupEducation · admissions and fee operations · live since June 2026
The compliance queue that used to be a spreadsheet
Delivered by Nithish Singh through Adidev Industries, January–July 2026, before Doing AI existed.
Name withheld under the confidentiality clause of the governing agreement. It can be released if the client agrees in writing.
Before
Admissions ran across twenty repositories and a dozen services, and the checks that decide whether a student's documents and fees are in order lived beside them in spreadsheets and inboxes. Nobody could say what was outstanding without assembling the answer by hand, and a fee ledger that read zero silently blocked students from paying at all.
What we built
A compliance audit workflow taken from beta to production across the admissions dashboard and four backend services: a live verification queue with per-document status, round-robin assignment to named agents, an audited contact-edit path with OTP, role separation between manager and agent, and a payment receipt pipeline. It runs inside the systems the team already used — no new tool to log into.
- Revenue double-counting corrected
- ₹3,14,000
- Self-paid orders on the deactivated source system, reversibly cancelled during the migration so finance reconciled against the real records.
- Share of all engineering across the platform
- 15.6%, ranked 1st of 43
- Authored non-merge commits across 20 repositories, 1 Jan – 2 Jul 2026, identities normalised and bot commits excluded. Reproducible from source control.
- Production deployments in the heaviest month
- 43
- Automated image updates through CI to the production cluster during June 2026.
How this was measured: Every figure is taken from monthly engagement reports prepared for the client's finance and management review, each derived from source control and production records rather than estimated afterwards.
How you can check it: The contribution figures are reproducible from git history across the twenty repositories, with author identities normalised and bot commits excluded. The report they come from was delivered to the client's own finance and management for review, not written afterwards for a website. We will walk a prospective client through it under NDA.
A global education groupEducation · finance and accounting operations · live since July 2026
The ledger balanced until somebody actually checked
Delivered by Nithish Singh through Adidev Industries, July 2026, before Doing AI existed.
Name withheld under the confidentiality clause of the governing agreement. The defects below are described by kind and scale; the underlying amounts are the client's own figures.
Before
The accounting export that fed the finance system ran every month without errors, so nobody had reason to doubt it. It was wrong in five separate ways at once. A whole class of recovered payments was being discarded by a filter that named the payment types it accepted; admission vouchers were missing from the journal entirely; one collection was booked twice with both legs claiming the same payment; and the export was unscoped, so other institutions leaked into a single institution's books.
What we built
The export was rebuilt and then corrected against real accounting data — each defect found by reconciling the journal rather than by a test failing. The payment-type whitelist was removed rather than extended, because adding the missing type would only have guaranteed that the next unanticipated one was dropped just as silently. Revenue is now keyed by intake cohort rather than payment type, vouchers clear at the money that actually arrived, and a loan counts as a loan only once the lender has disbursed.
- Recovered payments silently discarded
- 304 of 304
- A payment class matching neither branch of an accepted-types filter, dropped in full — a 100% loss with no error raised and no failing test.
- Student fee ledgers showing a wrong paid amount
- ~28,000
- Roughly 95% of all paid ledgers, where the paid column was double-counted platform-wide. Fixed and shipped 31 July 2026.
- Distinct reporting defects found by reconciliation
- 5
- Each identified by reconciling the general ledger against source records, not by an alert, an exception or a failing test. None had ever surfaced as an error.
- Student records migrated, each ledger-verified
- 158
- Four migration operations, every one dry-run before commit and checked against the live ledger rather than a database read-back. No money moved.
How this was measured: Every defect above was found by reconciling a general ledger against the systems that produced it, and every figure comes from the monthly report prepared for the client's own finance review. The money amounts involved are the client's and are not published here.
How you can check it: Each defect is recorded against the commit that fixed it and the production release it shipped in. The client's finance team reviewed and accepted the corrections — the strongest verification available for accounting work, because the party who would object is the party who signed it off.
A global education groupEducation · student communications · live since April 2026
Adding one WhatsApp message used to mean a deploy
Delivered by Nithish Singh through Adidev Industries, April 2026, before Doing AI existed.
Name withheld under the confidentiality clause of the governing agreement. It can be released if the client agrees in writing.
Before
Transactional WhatsApp messages were hand-coded per institution or pushed through a legacy mailer with no campaign routing. There was no kill switch, no way to build the parameters for a new event, and adding one meant editing the binary and redeploying. Three institutions each needed a different message shape, so each new message multiplied.
What we built
One communications backbone across WhatsApp and email, driven by configuration rather than code. Nine student lifecycle events wired through per-event parameter builders, per-institution template shapes, a kill switch, and defaults moved into config so a new campaign works in production without a release.
- Institutions live on one shared pipeline
- 3
- Each with its own template-parameter shape, previously requiring separate hand-written handling.
- Student lifecycle events wired
- 9 + welcome + document rejection
- Enquiry, interview cleared and not cleared, fee verified, and the registration and course fee events, each with its own parameter builder.
- Redeploys needed to launch a new campaign
- None
- Defaults merged into configuration, so campaigns are added without touching or shipping the binary. Previously every new event required a code change and a release.
How this was measured: Taken from the April 2026 engagement report, which records each change against the service it shipped in. The pipeline built here is what allowed a new institution to launch the following month with no per-event work at all.
How you can check it: The claim that a new campaign needs no release is checkable the plain way: the next institution went live the following month without a single per-event code change, which is recorded in the May report.
A global education groupEducation · internal operations · live since May 2026
Four internal tools became one platform
Built by Nithish Singh at Adidev Industries, May–July 2026, before Doing AI existed. The platform is Adidev's own work rather than a change to the client's systems.
Name withheld under the confidentiality clause of the governing agreement. It can be released if the client agrees in writing.
Before
The path from a sales enquiry to an admitted student ran through four separate internal applications — a sales intelligence tool, a reporting tool, a set of dashboards, and an internal app — none of which agreed with the others. Finance reconciled bank statements to receipts by hand, in spreadsheets.
What we built
One platform carrying the whole funnel: a governed data warehouse with dimensional modelling, a bank-statement reconciliation engine with rule-based matching and a manual workbench for the rest, scheduled reporting, and operator surfaces for the teams that use it. Role and row-level security throughout, with an append-only audit log.
- Internal applications consolidated
- 4 → 1
- A sales intelligence tool, a reporting engine, dashboards and an internal app, replaced by a single platform on its own cluster.
- Access control model
- 79 permissions across 26 resources
- A resource-by-action permission system with ten system roles and row-level security, replacing per-application access rules.
- Manual finance reconciliation
- Replaced by a workbench
- Bank-statement to receipt matching moved from spreadsheets and hand-matching to rule-based ingestion with exact-reference matching, delete-with-undo, and suggestions for the remainder. A recurring monthly task, not a one-off.
- Production deployments in one month
- 28
- Date-tagged image deploys during July 2026, on a platform sustained across all 31 days of that month.
How this was measured: Figures come from the May, June and July 2026 engagement reports. Commit counts are deliberately left out: they measure activity rather than value, as those reports themselves note.
How you can check it: The platform runs in its own namespace with date-tagged image deploys, so its release history is a matter of record rather than recollection. The permission model can be read straight out of the schema.
BillGill — our own productSales operations · any sector that runs a phone team · live since 2026
The call data existed. Nobody could act on it.
Built and operated by Adidev Industries. Live.
Before
Call activity lived in two separate telephony systems that did not talk to each other, and neither connected to the sales pipeline. Answering the only question that mattered — is calling activity actually producing enrolments — meant exporting from both, matching by hand in a spreadsheet, and accepting that the answer was already out of date.
What we built
A call analytics platform that ingests both telephony sources into one place, joins them to pipeline outcomes, and reports employee productivity, lead status and sales performance from a single view. A key-gated public API exposes the same data to other systems, so the numbers stop being retyped.
- Telephony systems unified
- 2 → 1 view
- Two call platforms previously reconciled by hand, ingested into one schema with sentiment and scorecard reporting on top.
- Calling joined to outcomes
- Closed the loop
- The platform reads the enrolment warehouse directly, so calling activity and what it produced are answerable in one query rather than two exports.
- Integration surface
- Key-gated public API
- Documented read-only endpoints with case-insensitive filtering, so downstream systems consume the data rather than re-entering it.
How this was measured: Described from the product itself and from the monthly reports that record its development and its security-audit pass.
How you can check it: It is our product, so the whole of it is available to look at — the running system, the API and its history. Nothing here depends on a client confirming anything.
SolveX — our own productReporting and finance operations · any multi-system business · live since 2026
Eleven reports that used to be assembled by hand
Built and operated by Adidev Industries. Live.
Before
The numbers that finance and operations needed were spread across five separate databases and two payment gateways. Every recurring report meant pulling from each, reconciling the differences, and rebuilding the same spreadsheet — every period, by a person, with the errors that implies.
What we built
A reporting pipeline that pulls all seven sources into one warehouse and generates the reports directly from it: eleven report types across four institutions, delivered as spreadsheets by email or self-service, on a schedule. Loan and lender reconciliation, per-order renewal detection and settlement tracking are computed rather than assembled.
- Sources consolidated
- 7 → 1 warehouse
- Five operational databases and two payment-gateway APIs, previously exported and reconciled separately for each report.
- Report types generated automatically
- 11
- Across four institutions, delivered by scheduled email and self-service download instead of being compiled and sent by hand.
- Reporting effort per period
- Recurring, not one-off
- The saving repeats every reporting period rather than being a single migration — which is the difference between a project and an asset.
How this was measured: Described from the product and from the monthly reports covering its build and its cross-cloud repointing onto managed database clusters.
How you can check it: Ours to show in full. The report definitions, the warehouse schema and the scheduling are all inspectable, and the outputs are the ones finance actually uses.
A global education groupReporting integrity · any business that exports data · live since April 2026
The export quietly returned ten rows
Found and fixed by Nithish Singh at Adidev Industries, April 2026.
Name withheld under the confidentiality clause of the governing agreement.
Before
A listing endpoint that fed management reports had a default: when no row limit was passed, it returned ten. Not an error, not a warning, not a truncation notice — ten rows, correctly formatted, indistinguishable from a complete answer. Every report built on it had been quietly wrong for as long as it had existed, and nothing anywhere would ever have said so.
What we built
The silent default was removed and replaced with an explicit ceiling high enough to return the real answer. The wider lesson was applied where it belonged: a query that cannot return everything should say so, rather than returning a plausible fraction.
- Rows a full export actually returned
- 10
- The unlimited case fell through to a ten-row default. Reports were built on it and read as complete.
- How it announced itself
- It did not
- No error, no exception, no failing test. The bug was found by someone reading the code path, not by anything the system reported.
- Class of defect closed
- Silent truncation
- Fixed at the default rather than at each call site, so a future caller that forgets a limit gets the answer instead of a fraction of it.
How this was measured: Recorded in the April 2026 engagement report against the commit and service that fixed it.
How you can check it: This is the kind of defect worth judging us on, because it is the kind nobody is paid to find. Ask us on a call what we would look for first in your reporting, and see whether the answer sounds like someone who has been here before.
A regulated institutionRegulated review · lending, claims, onboarding, compliance · live since May 2026
Three pairs of eyes, and a record of whose
Delivered by Nithish Singh through Adidev Industries, May 2026.
Name withheld under the confidentiality clause of the governing agreement.
Before
Approvals that regulation required to pass three separate reviewers were tracked as a single yes or no. Who checked what, in which order, and on what basis was reconstructed afterwards from memory and email — which is the same as not having it, on the day somebody asks.
What we built
A configurable multi-tier review pipeline: three reviewer levels with distinct roles and permissions, per-document routing between them, and an audit trail written as the work happens rather than assembled afterwards. Institutions with different approval rules configure the pipeline instead of getting a fork of it.
- Review tiers with separate roles
- 3
- Each tier a distinct role with its own permissions, so a reviewer cannot complete a stage that is not theirs.
- Audit trail
- Written as it happens
- Captured at the moment of each decision rather than reconstructed later, which is the only version that survives being questioned.
- Configurable per institution
- Yes
- Approval rules are configuration, not a code branch — so a second institution with different requirements does not become a second codebase to maintain.
How this was measured: Taken from the May 2026 engagement report, which records the role model and the tier that completed it.
How you can check it: The permission model and the audit schema are the artefact — they can be read directly and either separate duties properly or do not. The institution it was built for is regulated, and accepted it.
A global education groupBilling and pricing · any business with discounts or instalments · live since June 2026
Nobody could agree what was actually owed
Delivered by Nithish Singh through Adidev Industries, March–June 2026.
Name withheld under the confidentiality clause of the governing agreement.
Before
What a customer owed was computed in more than one place, and the places disagreed. Discounts were applied against a price that could change after the fact, so historic orders stopped resolving. Some charges were excluded from the calculation entirely, leaving balances that read as nothing owed. Finance, the operations team and the customer's own screen could each produce a different number, and each could defend it.
What we built
One calculation, used everywhere. Historic prices are pinned so a past order still resolves against the price it was actually sold at, every charge type is included in the balance, instalments carry a running per-period balance, and the amount paid is stored as the amount paid rather than derived from a discount.
- Balances reading zero when money was owed
- ~11,000
- Applications whose ledger showed nothing payable because a charge type was excluded from the calculation, so the customer could not pay even if they wanted to.
- Historic orders that stopped resolving
- Fixed at the source
- The first price and discount row of each chain was backdated, so orders paid under an earlier price resolve correctly instead of failing.
- Places the amount owed is now computed
- One
- Previously several, each defensible and none authoritative. Disagreement about the number was the defect, not any single wrong answer.
How this was measured: Drawn from the March to June 2026 engagement reports, each fix recorded against the release it shipped in.
How you can check it: The corrections were accepted by the finance team who had been living with the discrepancy, which is the only sign-off that means anything on a billing question.
Adidev Industries — our own operationsDelivery reliability · any team shipping to production · live since July 2026
Nine portals that could not ship themselves
Diagnosed and fixed by Nithish Singh at Adidev Industries, July 2026.
Before
The automation that promotes a built image into production had stopped being able to write back, so every release was being nudged along by hand. Nothing was broken loudly enough to raise an alarm; it had simply become normal for a person to do the last step, and nine portals were frozen behind it.
What we built
The cause was traced to an access token holding a permission level too low to write, rather than to the deployment tooling everyone suspected. Fixed at the credential, the automation resumed, and the portals unfroze.
- Portals unblocked
- 9
- Each frozen behind the same write-back failure, all released once the underlying permission was corrected.
- Root cause
- A token, not the tooling
- A guest-level access token that could read but not write back. The deployment system, which had absorbed the blame, was working correctly throughout.
- Manual steps per release
- Back to zero
- Hand-bumping had quietly become the routine. The fix removed the step rather than documenting it.
How this was measured: Recorded in the July 2026 report as a production infrastructure blocker, alongside the releases it unblocked.
How you can check it: Our own infrastructure, so there is nothing to take on trust — the deployment history shows the gap and shows it closing.