Our process - How we work
We start with a free audit — 48 hours, a map of bottlenecks on your real catalog. Then we separate base scope from optional blocks and estimate the first work slice. After that: weekly demos every Friday, a zero-downtime launch, SLA from day one.
Audit
Every project starts with a free technical audit — 48 hours. We review your site, stack, speed and catalog, and check integrations. You get a map of bottlenecks, a base scope and the decisions that affect budget.
Not a presentation or a wireframe mockup. You know upfront what we'll migrate from your Bitrix and how — before signing a contract for the full project.
After the audit you receive: a map of bottlenecks, a compact functional requirements structure, base and optional scope, a preliminary budget range and the next work slice to test speed and workflow.
Included in this phase
- Free audit (48 hours)
- Bitrix API technical audit
- Integration map
- KPIs and success metrics
- Base and optional scope
- Map of bottlenecks and acceptance criteria
Development
Every Friday — a demo on the staging domain. Working code you can open in a browser and test. No slides, no ‘in progress’ status updates.
Direct access to the developer via Telegram. Priorities can shift at the start of each week. If scope, integrations, roles or workflows change, we estimate and approve the change request before development.
For custom work we don’t sell vague guarantees. We define the milestone, acceptance criteria and the next step that opens after the demo.
Launch
We route 5% of traffic first — monitoring errors and metrics. Then 25%, then 100%. At each step there’s an automatic rollback: if something goes wrong, we’re back in 5 minutes.
Before switching, we run automated tests (Playwright, Lighthouse) on all key scenarios: catalog, search, cart, checkout. Green across the board before we go to production.
After launch: the full repository, architecture docs, runbook. You don’t depend on us for day-to-day operations.
Included in this phase
- Testing. Playwright e2e + Lighthouse before every deploy across all key user flows.
- Infrastructure. Vercel for the frontend, your Bitrix for the backend. Need a closed environment — we deploy to your cloud.
- Support. SLA starts day one after launch. Three tiers: from 24-hour response to 24/7.
Before estimation
What we need to understand before budget
For custom development we do not promise a fixed price before discovery. First we build a compact project map so the owner, CTO and marketing team can see what drives the estimate and which first step can be tested without large risk.
How we operate - Six rules we don't break
Twelve years in e-commerce taught us: clients don’t suffer from technical problems — they suffer from unpredictability. Here’s how we address that.
- Scope before budget. We define requirements, base scope, optional blocks, integrations and acceptance criteria first. Only then do we give a working estimate.
- Demo every Friday. Not reports — working code on the staging domain. Bring your team, test it yourself.
- Zero-downtime launch. Gradual traffic shift: 5% → 25% → 100%. Automatic rollback in 5 minutes if something goes wrong.
- Your code. After launch we hand over the full repository and documentation. No lock-in.
- Audit first. We don’t start a full project without an audit. In 48 hours we give you a map of bottlenecks, base scope and a clear next work slice, then you decide.
- We say no. If a job isn’t the right fit for us, we’ll say so directly and recommend someone else. Taking everything that comes in isn’t our model.
What you see after the audit - Decision artifacts, not a vague promise
After 48 hours you do not get an abstract “we will make the site faster” claim. You get the project structure: what belongs in the first phase, what depends on integrations, and which slice can be tested before a larger budget.
- Scope map. Base scope, optional blocks, external dependencies and acceptance criteria in one document your owner, CTO and marketing team can review together.
- Risk list. Bottlenecks across catalog, search, API, caching and release process, marked by impact on timeline, budget and downtime risk.
- First work slice. A small next phase: limited scope, demo checkpoint and criteria that show speed, quality and workflow before a full rollout.
When we are useful - We quickly check whether it makes sense to continue
The audit should not only produce a task list. It should also answer whether WGP is the right partner for your stage. We are most useful when the site already affects revenue and changes have become risky or too slow.
- Good fit. Catalog, search, integrations, roles, SEO or release speed have become a constraint. You need to change the system in phases, without stopping sales and without a blind rewrite.
- Risk check first. Before budget, we review data, access, APIs, release process and acceptance criteria. If the problem can be solved with a smaller intervention, we will say that directly.
- Poor fit. If you need only a cosmetic redesign, an urgent landing page without an engineering problem, or a fixed price before discovery, we will not sell a full project.
Pre-start check - What we inspect before an estimate and a larger budget
For an owner, CTO and marketing team, the audit should remove blind spots quickly: where the site loses speed, sales or control, what data is needed for the decision, and which next phase can be tested with a small scope.
- Catalog and search. Listing speed, filters, search relevance, SEO structure, indexing and scenarios where users most often lose the path to the product.
- Integrations and roles. 1C, CRM, payments, delivery providers, marketplaces, access roles and places where external dependencies can affect timeline, budget or a zero-downtime launch.
- Release process. How changes work today: Git Flow, staging, tests, metrics, rollback and who accepts the result. This shows whether to start with a pilot/work slice or close infrastructure risk first.
Control checkpoints - How the client sees the project is under control
For a complex site, speed is not enough. The client needs to see where risk is closed with facts. Every stage has a verifiable artifact: a link, metric, test or document that supports a decision without asking anyone to trust vague promises.
- Before development. We capture the baseline: speed of key pages, catalog and search flows, integrations, roles, migration data and acceptance criteria for the first work slice.
- During the project. Every week we share a staging link, completed tasks, scope changes and the risks still open. The client sees the code and can test scenarios before release.
- Before launch. We run the production checklist: e2e flows, Lighthouse, forms, analytics, rollback path, owner map and a runbook for the client team.
Proof before a decision - What you can show a partner, CTO or budget owner
After the audit your team gets a short evidence pack, not a long presentation. It can be shared internally to approve the next work slice without turning the decision into a debate of opinions.
- Before / after baseline. We capture current speed, search, indexing and key-flow signals so the next phase is compared against the real site, not an abstract promise.
- Scope decision table. We separate required scope, optional blocks, external dependencies and client questions. This helps agree on a budget range without fixing a price before discovery.
- Next-step recommendation. We recommend a small verifiable step: audit follow-up, pilot, integration spike or release-process support. The format depends on the risk, data and business goal.
- Internal approval note. A short summary for the owner, CTO or partner: what we found, what we would do first, which assumptions affect the estimate and what evidence should be checked before a larger commitment.
- Path to the next action. Contact link, required inputs and UTM attribution stay in one route, so it is easier to see which conversations came from the process/audit page.
First message - What to send so we can return with a specific next step
You do not need a long brief to start. We need enough context to understand the risk and suggest the smallest useful work slice: audit, pilot, integration spike or release support.
- Site link and constraint. Current site or staging link, plus the main constraint: slow catalog, weak search, manual exchanges, release risk, SEO or conversion.
- Critical flows. 3–5 routes that must not break: category, filter, search, product page, cart, checkout, customer account or B2B roles.
- Integrations and data. What is connected to the site: ERP, CRM, payments, delivery providers, marketplaces, analytics, external APIs, imports/exports and common error points.
- Decision constraints. Timeline, client-side team, data availability, SEO requirements, expected demo checkpoint and budget drivers.
FAQ
Common questions about our process
What is the audit and why does it matter?
The audit is a free technical review over 48 hours. We look at your site, stack, speed and catalog, and check key flows and integrations. You get a map of bottlenecks, base scope, optional blocks and a preliminary estimate. You decide whether to proceed with the full project after seeing the work structure and budget drivers.
How much does the audit cost?
The audit is free and takes 48 hours. It ends with a bottleneck map, base scope and preliminary estimate. Get in touch — we'll run the audit on your catalog.
When do we get a precise estimate?
After discovery we define requirements, integrations, roles, workflows, acceptance criteria and optional blocks. Productized Frontbox formats can have fixed pricing; custom development depends on scope and is estimated by milestone or work slice.
What should we send so the audit is specific?
A link to the current site, 3–5 main business tasks, integration list, user roles and timeline constraints. If you have speed, SEO, conversion, search or error data, include it. That helps us separate base scope from optional work faster and avoid guessing the budget.
What happens if requirements change mid-project?
Priorities can shift once a week, at the start of each sprint. New features beyond the agreed scope are estimated and approved separately. Shifting priorities within the agreed scope does not change the current milestone.
How often do we see project progress?
Every Friday — a demo on the staging domain. Working code you can open in a browser. Plus daily short updates in the project's Telegram channel.
What does a zero-downtime launch mean?
We route 5% of traffic to the new frontend first, watch metrics, then 25%, then 100%. At every step there's an automatic rollback. If something goes wrong, we're back to the previous version in 5 minutes. Your Bitrix and all orders keep running throughout.
What do we receive after launch?
The full code repository, architecture documentation, a runbook for your dev team, and deployment instructions. Everything you need to operate independently.
How does post-launch support work?
SLA starts on day one after launch. Basic — 24-hour response during business hours. Professional — 8-hour response, extended hours. Enterprise — 2-hour response, 24/7. More details on the support page.
Start with a free audit
48 hours, a map of bottlenecks on your catalog, base scope and the next work slice. Then you decide.