When a service is sold by hand, scale runs into people: a manager pulls the data, raises the invoice, and sends the result. Want to serve ten times more clients? Hire ten times more managers. Or move the service to self-service. DocMarket is designed as that second path: a manual service turned into a standalone site with automatic payment and a user account.
Snapshot
| Industry | Product certification, B2B logistics |
| End client | Certificate Analytics (new product in the line) |
| Engagement | Direct spec for a standalone new product |
| Project type | An MVP web service for self-service sale of data exports from certification registries |
| MVP scope | Registration, a user account with billing details, a preview filter with hidden sensitive fields, pay-by-invoice and by card, promo codes, automatic delivery of the result, notifications, read-only integration with the platform’s main database |
| Project date | 19 March 2026 — under review on the client’s side |
| Effort | not estimated — the spec includes an analysis stage, after which the hours are quoted |
| Team | Anton Hersun (project lead). The implementer is to be decided — we’re weighing the main-platform developer against the widgets/parsers developer; the choice depends on how the technical integration lands |
| Tech stack | A separate web service (probably Laravel, like the rest) · read-only integration with the main database · own database of users and orders · card acquiring and pay-by-invoice · user account with phone and email registration |
| State | Final spec (tz37_docmarket_mvp_final.docx) handed over 26.03.2026; the client took it for review, no further movement in correspondence |
The problem
The client already runs a manual service: managers pull data from certification registries for Russian logistics firms. Logistics firms use third-party certification documents by number without a power of attorney, and this is legal under the relevant regulation. The demand exists and was confirmed at an industry logistics expo. The problem is elsewhere: different managers use different export criteria and different prices. That’s hard to control and even harder to scale.
DocMarket is being built as a standalone web service that automates the process. The client set the format up front: not a full platform end to end, but a minimum working version that can be extended. The core of the MVP:
- Registration by phone or email with confirmation.
- User account: profile, company billing details, purchase history with re-download.
- A preview filter across registries with limited visibility of the result, available without login to draw clients in.
- On-site payment: by invoice for companies and sole traders, by card for individuals; promo codes.
- Automatic delivery of the full export after payment is confirmed, with notifications in the account and by email.
Why this is hard. The most fragile spot in self-service over registry exports: show the client enough to grasp the value, and not enough to find the data on their own. Show full numbers and dates in the preview and the client goes off to search the open registry, buying nothing. Hide everything and they don’t understand what’s inside, so they don’t pay. The balance of “show the structure, hide the identifiers” is a core product decision, not a technical patch, and it has to be agreed with the client before development starts.
How we did it (at this stage)
1. The final spec as the outcome of the call with the client on 19 March 2026.
Verbal agreements get lost within a week, so we hold the “call → concept → spec” format strictly. The client first sent a concept document (Project - DocMarket.docx), the call ran in Telemost, and within a week of it we assembled the final spec (tz37_docmarket_mvp_final.docx, handed over 26.03.2026). The recording of the meeting is the only way, a month later, to remember why exactly this went into the spec and not something else. The discipline is simple: fix the concept on paper, discuss it by voice, fold it into one spec, not “let’s start coding.”
2. The MVP boundary was drawn deliberately.
In the concept the client described the “ideal” export: a document should be filterable by being a serial document, valid by date, by status in the national registry (KG, KZ, Belarus), by status in the EAEU registry (pub.fsa.gov.ru/reaec/conformityDoc), and by legislation, and that last one lives only in regulations on paper and is entered by hand. Five conditions mean five different sources and online checks. In the MVP we kept two automatic filters: serial documents only, and valid-by-date only. The three status checks moved to a second phase. That way the MVP gets a working product without depending on live external registries, and the heavy part moves to the next stage. This is a decision about scope, not “let’s do everything at once.”
3. Limited visibility in the preview: a product decision baked into the architecture.
The spec states it plainly: in the preview the document number is fully hidden, only the year remains of the dates, and the other critical fields are marked “hidden” or blurred. The exact list of hidden fields is set by the client at the design stage. One thing is non-negotiable here: blurring can’t be “added later.” It affects the structure of database queries and the rendering templates, so it’s built into the architecture from the start.
4. A user account with company billing details for invoicing.
The accounting departments of the buyer logistics firms won’t process a payment without an invoice carrying billing details: for a legal entity that’s a condition of the deal, not a convenience. So the account holds a company profile and a “download invoice” button on any purchase, and the invoice itself is assembled automatically from the account’s billing details.
5. We don’t estimate hours until the analysis stage is done.
The hours line in the work plan is left empty, and that’s deliberate. DocMarket connects to the platform’s main database, which is in its fourth year in production, and the integration runs strictly read-only: a separate site must not be able to write anything or break anything in production. How to grant such access safely is what the first analysis stage decides. The second risk is named honestly in the spec itself: acquiring connection timelines drift, because banks have different procedures for test and live access. Naming a final estimate before working through these forks would be guesswork.
Results (current state)
| Metric | Value |
|---|---|
| Hours | not estimated — the work plan includes an analysis stage, after which the estimate is given |
| Spec | Final version tz37_docmarket_mvp_final.docx, handed over 26.03.2026 |
| Status | On the client’s side, under review; build not started |
| Artifacts | Concept Project - DocMarket.docx, Telemost call 19.03.2026, final spec |
Where it stands today: the concept went through the “concept → call → final spec” cycle with every step recorded in writing, the MVP is separated from the future part, and the dangerous integration spots are named in advance. Next comes the analysis stage for integration with the main database, then the hours estimate and the start of the build. The decision rests with the client.
Process and timeline
| Stage | Period | Result |
|---|---|---|
| Concept from the client | 19 March 2026 | Project - DocMarket.docx |
| Call with the client | 19 March 2026 | Discussion in Telemost, recording |
| Final spec | 19–26 March 2026 | tz37_docmarket_mvp_final.docx |
| Analysis stage | not started | Database analysis, filter scheme, list of hidden fields, hours estimate |
| MVP build | not started | By the agreed plan |
Team
- Anton Hersun, Xaver Pro: project lead, formalizing the spec, drawing the MVP boundary
- Implementer to be decided. We’re weighing two: the main-platform developer (he knows the analytics database from the inside, which lowers the risk of breaking something in production) and the widgets/parsers developer (if DocMarket turns out closer in architecture to the Bitrix integrations). The choice comes after the analysis stage and the work on integration with the main database.
Screenshots and materials
Empty for now: the MVP isn’t built.
If you’re planning to move a manual B2B service to self-service, we’ll share our stage-by-stage method: “concept → meeting → final spec” with every step recorded in writing. We’ll show you the forks that come up between “show the value” and “give everything away.” The review is free.