Work Slice Before Rewrite: How to Test a Project and a Team

When a project already hurts, the natural request is: "Give us an estimate for the whole rewrite."

Then a spreadsheet appears: 4-6 months, a list of risks, a large budget and a feeling of control.

The problem is that this control is often fake. Before a team has seen the repository, staging, CI/CD, data, roles, integrations and real user flows, a large estimate looks precise only on a slide.

I prefer to start smaller: with one work slice.

What a work slice means

A work slice is not a free "quick look" at the project. It is also not an attempt to solve everything immediately.

It is a limited piece of real work after which three things become clearer:

how maintainable the system actually is;
how the team thinks, communicates and makes trade-offs;
what requirements are needed before the next stage can be estimated honestly.

For example: get the project running locally or on staging, walk through one critical user flow, find where the catalog loses data or slows down, write a minimal runbook and propose the next step.

If the stack is Bitrix, Laravel, Next.js or Elasticsearch, one such slice often tells more than a week of calls.

Why a large estimate before discovery is risky

In legacy projects, cost rarely hides in obvious screens. It hides in operational details:

who owns access;
whether staging can be deployed safely;
where secrets and cron jobs live;
how CRM, 1C, payments and delivery integrations work;
whether documentation exists or everything depends on one person's memory;
what "done" means for the business, not just for a developer.

Without those answers, a fixed estimate for custom development becomes an argument about who pays for the unknown.

The healthier sequence is smaller: collect context, separate base scope from optional work, define acceptance criteria and only then estimate the next stage.

What a good first slice includes

I usually look less at "how many screens we need to design" and more at project control:

repository and change history;
local setup or staging;
CI/CD and rollback path;
data structure and API contracts;
one critical flow: catalog, search, checkout, lead form or account area;
logs and metrics, if they exist;
documentation that would help a new team continue the work.

The output should not be a beautiful PDF. It should be a short map: what blocks progress, what can be fixed without a rewrite, where a rewrite is justified and which risks need to be closed first.

What this shows about a contractor or senior engineer

A small slice quickly exposes working style.

Someone either asks to rewrite everything immediately or tries to understand what already earns money and should not be broken.

Someone either promises an exact price before seeing the system or clearly separates knowns from unknowns.

Someone either hides the process or shows Git Flow, review, staging and verification criteria.

For a CTO or founder, this is more useful than choosing by portfolio. You see a small model of future work, not just a promise.

When a slice is not needed

If the task is simple and repeatable - a landing page, a small site, a standard integration without complex data - it can usually go straight into a normal estimate.

But if the project is already live, depends on integrations, earns money and feels risky to touch, a work slice is almost always cheaper than a large mistake.

The point

The first step in a troubled project is not a heroic rewrite. The first step is making the system a little more understandable.

A small work slice does not replace strategy. It removes fog before strategy: real constraints, communication quality and the cost of the next decision become visible.

If you are looking at a legacy project and cannot tell whether to fix it or rewrite it, do not start with a large estimate. Start with one verifiable piece of work.

For a commercial e-commerce problem, the WGP path is a compact technical audit / Catalog Probe: catalog, search, integrations, SEO risks, base scope vs optional scope before estimation.