An admin B2B-analytics core in 342 hours: Laravel 8 and Sencha 6

A from-scratch platform can fail two ways. Rush the core for speed, and by the third or fourth round of changes you start rewriting it. Polish the architecture with no eye on the schedule, and the client stops understanding what they’re paying for while the project stalls at the start. We split those risks at the contract level: there were two. The first closed the core, the second added modules, and from day one one rule held: don’t rush the core for the modules. From the first contract to delivery was 152 days. Everything else later grew on that core: over the next four-plus years, several dozen orders and specs came through the same chat, and not one needed the core rewritten.

Snapshot

The problem

The client works with the product-certification market. They already had an analytics system, tuned for a narrow set of data, and they decided to retire it. They needed a new platform that could hold state registries with different data structures inside one analytical environment and keep evolving for years, not just until the first major change.

The client wrote the spec by functional section: “Accredited bodies”, “TR CU declarations”, “Conformity certificates”, and so on. The platform was meant as an internal admin interface: no public side, no external API, access for the group’s staff only.

Why this is hard. The risk in hiring a partner for from-scratch development is plain: six months in, the core hits architectural limits, and you pay a second time for something you just put into production. At the moment the spec is signed, the client doesn’t yet know which of the listed sections will become central in a year and which will fall away. So we built the core for the tenth iteration, not the first: each section is a standalone unit, we wrote no shared code between sections, and we put the acceptance points for the core and the modules on separate tracks.

How we did it

1. Two contracts instead of one: core first, then modules.
Contract No. 1 of 17 September 2021 closed the core only: the server side on Laravel 8 and PHP 8 (80h) and the client side on Sencha 6 (90h), 170h in total. Contract No. 2 of 22 September added modules on top of the core: a tabular-data builder, connection of existing databases, Excel export, filter-search-grouping, archiving, and code documentation (172h). The budget gained two acceptance points: the client saw a working core, and only then did the modules begin.

2. Sencha 6 (ExtJS) for the admin side, not React.
“Why not React?” was the question we heard most in 2021. Because this is an admin interface with heavy tables of hundreds of thousands of rows: the Sencha grid carries them out of the box, while React would need a stack of third-party libraries bolted on. The second reason was the stated support horizon: as of 2021, Sencha 6 had seven-plus years, and for an internal B2B tool that weighs more than how fashionable the stack is. By 2026 the choice paid off: the interface was never rewritten for “technology” reasons, only extended for new modules.

3. Each section as a standalone module, no shared code between registries.
There are several registries, and each has its own field structure. Tie them together with shared code, and any change for one registry breaks its neighbor. So we did it differently: one shared builder for the tabular display, plus a separate field config for each section. Adding a new registry means a new config and, if needed, a separate source parser. You don’t touch the shared code. The decision paid off more than once. When an “Accredited bodies” module of roughly 30,000 records was needed a year later, it plugged in as a new section with no changes to the core.

4. Code documentation as a separate 10-hour line in the estimate.
Contract No. 2 has an explicit line: “Documentation of program code, 10h”. On from-scratch projects this is rare: documentation usually gets pushed to “later”, and “later” never arrives. Here it went into the scope and was delivered at acceptance with everything else. For the client it’s insurance against a change of developer: one person has run the account from day one, but if it ever has to be handed off, there’s a starting point.

5. A field builder instead of a hard-coded list in the code.
The main architectural decision of the modules part, 40 hours in the estimate: the admin chooses the fields for display, detailed view, export, and search themselves, and binds tables to menu sections. Without the builder, every change to a field list would mean a code edit and a new release. With it, configuration runs through the interface, no restart. That same builder later became the basis for all the tabular reports and group statistics that grew on top of the platform over the following months.

What the first winter of operation showed

The old system wasn’t switched off on delivery day. It was wound down gradually, as the new platform took on the data, and access to the old analytics tool was finally closed in early March 2022, once the client confirmed it was no longer needed. The caution paid off.

In January 2022, while migrating historical data, a defect in the old storage schema surfaced: dates had once been copied by a wrong algorithm, and in roughly 26,000 records from 2018 the day had turned into the year. The source of the bad edit in the old system could no longer be found. We worked out the algorithm, fixed the corrupted records, and moved the historical layer the client didn’t need in the main table into an archive. This is where the archiving module from Contract No. 2 earned its place: data isn’t deleted or lost, it goes into a separate layer. In the new platform, dates have been stored as dates from the start, with no copy schemes, so a repeat of the incident is ruled out.

That same period brought the first orders on top of the core, and not all of them flew. One of the early modules, product search by TR CU and TN VED summary codes, we built in full: assembled a database of roughly 26,000 items, stood up the search forms, delivered against the act, and then the client never found a use for it in their work. Rather than tweak it pointlessly with the hours still left in the spec, we proposed closing the line ourselves and spending the remainder on useful small work: an honest “built, but found no use” is worth more than an act signed for the act’s sake. The idea didn’t die, though. In 2023 the client came back to it with a “proposals” module, where staff file request-proposals with statuses and correspondence. The spec was worked out and approved, but the client postponed the launch, and the status of this branch is unchanged: approved, not launched.

Results

What came out of it: an admin B2B platform with its own tabular-data builder, a modular architecture by registry, Excel export, and an archiving system. Over the following years, several large directions grew on that core: parsing of foreign registries, analytics and group statistics, a templated-document builder, and integrations with amoCRM and Bitrix24.

Process and timeline

Contract No. 2 was signed before the core was finished so the stages would overlap and the team wouldn’t sit idle between them. The gap between the sum of the work stages and the 152 calendar days is the client’s approval rhythm plus the usual holiday pauses.

Team

• Anton Hersun, Xaver Pro, project lead, architect, spec formalization, client-facing work
• Analytics-panel developer: has run the main platform from day one to today. Whoever wrote a module in 2021 still maintains it now. Any change years later stays in the hands of the same person, with no code handoff between people.

Screenshots and materials

To be added in a separate pass after sign-off with the client: the internal interface needs privacy processing before publication.

If you’re planning a from-scratch B2B-analytics build and aren’t sure what to pick in the stack, send us a brief and a list of integrations. We’ll say where you can save on standard modules and where you’ll have to write by hand. The review is free.

Discuss your analytics build →