You can test the recovery path before depending on it. Start with a small example and use a safe, separate test environment.

Check one useful record

Imagine a project planner that exports JSON. Create a test task with a recognizable title, export the file, then import it into an isolated test copy. Find the task and compare its details with the original.

Some applications replace current data during import. Read the warning and keep the test away from your working project. Protect any private data in the backup as carefully as the original.

Record the version you tested, the file used and the result. If important data is missing, investigate and make another copy before relying on it. Repeat the check after significant changes to the export or import process.

Keep track of the check

Launch Control Desk helps you organize release checks, owners, results and risks in a local workspace. It records your checks; it does not back up your service or run the restore for you.

RUB 1,190 for a one-time purchase: Get Launch Control Desk.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical checks for websites and digital products.

When did you last try restoring a backup?

Make your part visible

Imagine a team built an online shop and you worked on the delivery-address form. If that matches your real work, you could write:

Our team built an online shop. I added an empty-address check and a message that tells the customer what to enter. The screenshot shows the message after an empty submission.

This example is fictional. Use your own task and describe the actual contribution. A link to an accessible pull request, a screenshot or a demo can help support the specific claim. Credit other contributors where relevant.

If the project is private, share only what you have permission to share. An anonymized explanation or a separate sample can work; label a sample clearly.

Put the case together

Portfolio Case Kit is a local editor for your profile and project cases. It can export a portfolio website and GitHub README text. Save a separate JSON copy of your working data.

RUB 790 for a one-time purchase: Get Portfolio Case Kit.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical examples for projects and portfolios.

How do you show your part of a team project?

If the spreadsheet treated the code as a number, it may have removed the leading zeros. That matters when the code is an identifier: 001 and 1 can represent different records.

Check the source before changing anything

Open a copy of the original CSV in a plain-text editor and find a known code. Compare it with the version you saved from the spreadsheet. If the original says 001 and the new file says 1, the change happened somewhere between those versions.

A CSV can contain 001 as text, but a spreadsheet may interpret that value as a number when opening it. When importing a file, set the product-code column to Text in the import settings. Then inspect a few known IDs before saving a new copy. Quoting a CSV value alone doesn't guarantee that a spreadsheet will preserve its zeros.

If the zeros are already missing, don't add them back by guessing. Check the source system or an unchanged export to learn the real IDs. Different codes may have different lengths.

Compare two versions using the right key

CSV Reconcile Desk compares two CSV or TSV files by an ID column. It treats 001 and 1 as different strings, so they won't silently match. Select the fields you want to compare and review added, missing and changed records; duplicate and blank IDs are listed separately.

The app runs locally in your browser and can export a CSV or JSON report. It does not restore lost zeros or decide which code is correct; you need the original source for that. XLSX is not supported.

RUB 990 as a one-time purchase: Get CSV Reconcile Desk.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for simple ways to check files and avoid confusing data errors.

Have you ever seen an identifier change after a file was opened or exported?

Don't claim you've used the missing tool. Make the connection clear and describe the gap honestly.

Use one real example

Imagine a role asks for Docker, and you've deployed an application without using it. If that's true for you, a useful answer might be:

I haven't used Docker professionally. I have deployed a small application, configured its environment variables and checked the logs when it failed to start. I understand Docker packages an application and its dependencies into an image. I'm practising that workflow and can explain what I've tried.

That answer separates actual experience from what you're learning. Only include the final sentence if you really have started practising. If you haven't, say what you plan to learn next instead.

Then prepare to explain the real work: what was failing, what you checked and what changed. If it was a team project, make your own contribution clear.

Map the requirement before the interview

Write down three things: the requirement, the closest relevant task you've actually done, and what you still need to learn. Bring a brief example you can discuss, plus any evidence you can share without revealing confidential information.

Some requirements are essential for a role, and a related example may not replace them. The point is to give the interviewer an accurate picture of what you can do today.

Interview Proof Kit is a local workspace for connecting job requirements to your own stories, evidence, gaps and next steps. It includes practice prompts and lets you export your notes. It doesn't verify your claims or predict hiring outcomes. Save a separate JSON backup of your notes.

RUB 990 as a one-time purchase: Get Interview Proof Kit.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical examples for interviews and everyday development work.

What related experience would you use to explain a skill you're still learning?

Can they open the file and get a first result without asking for help?

A successful upload tells you the package reached the platform. It doesn't show what the buyer receives or whether your instructions match the package.

Try the buyer's route

Imagine you sell a downloadable template. Before release, get the file through the same delivery route a buyer uses, using a test purchase if the platform supports one. If you can't use that route without paying, check the available delivery preview and record what you couldn't test.

On a device or account without your working files, follow the steps as a customer would:

1. Download the delivered file and check that it opens.
2. If it's an archive, extract it and find the starting file mentioned in the instructions.
3. Follow the instructions to create a small example or open the included sample.
4. Check that the result appears and that the instructions explain how to save it, if saving is part of the product.

If you get stuck, record the step and fix the file or instructions. Then test again with a fresh copy.

Make the first instruction concrete: “Extract the ZIP, then open Start Here” is easier to follow than “Use the included materials.” Only name a file that's actually in the package, and tell buyers about required software before purchase.

Keep launch checks together

Launch Control Desk helps organize checks before release. You can assign an owner, record the outcome and see what still needs fixing. The package includes a local RU/EN app, examples and instructions. You perform the checks yourself; the app records the work.

RUB 1,190 for a one-time purchase: Get Launch Control Desk.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for simple ways to check a product before selling it.

What's the first action a customer should take after downloading your product?

That doesn't mean you have nothing useful to show. Explain what the project does and offer evidence a reader can actually check.

Turn a feature into an example

Imagine the tracker lets someone enter an amount, choose a category and see a monthly total. Here's a fictional way to describe it:

This personal project groups expenses by category. To check the total, add two expenses in the same month, then remove one and confirm the total changes. The demo and its test steps are linked below.

A reader can follow the example and inspect the behavior. That's more useful than claiming the app “improved productivity by 40%” when no such result was measured.

For your own project, use its real behavior and actual links. A screenshot, a test or a working demo can support a specific claim. It can't prove that people used the app or saved money.

Explain the limits, too

If it was a team project, say which part you built. Mention whether the example uses sample data and what the app doesn't yet handle. For instance, if entries stay in one browser, explain that before someone expects them to appear on another device.

A small, honest result gives readers a way to understand your work. Add measured outcomes later if you collect them.

Put the case together

Portfolio Case Kit is a local editor for presenting your projects. Add a profile and project details, then export a portfolio website or text for a GitHub README. The package includes instructions and fictional examples. Save a separate JSON copy of your working data.

RUB 790 for a one-time purchase: Get Portfolio Case Kit.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical examples for projects and portfolios.

What's one thing someone can try or inspect in your latest project?

Which row is correct? The two rows alone don't tell you.

Perhaps the item was duplicated by mistake. Or perhaps the rows refer to different warehouses, but the file doesn't include the warehouse name. Taking the first row automatically can produce a tidy-looking comparison with the wrong answer.

Separate the uncertain rows

Put repeated IDs aside for review. Check the original source and look for a field that distinguishes the records, such as warehouse or product variant.

Then decide what makes a record unique for your task. If one product can appear once per warehouse, the product ID alone isn't enough. You may need a key that includes both product and warehouse.

For example, A-17 / north and A-17 / south can represent two different records. Only use those labels if the source actually provides that distinction. Don't invent missing information to make the duplicate disappear.

You can continue comparing unambiguous rows while keeping uncertain ones visible in a separate review list. Fix or clarify the source before treating those rows as reliable.

Make the uncertain rows visible

CSV Reconcile Desk compares two CSV or TSV files by ID and shows new, missing and changed records. Duplicate and blank IDs are separated for review, and you can save the result as CSV or JSON.

The app runs locally in your browser. Extract the archive and open index.html. It uses one ID column, so if you need a combined key, prepare it in a separate column first. XLSX isn't supported.

RUB 990 for a one-time purchase: Get CSV Reconcile Desk.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical examples and tools for everyday work.

When you find duplicate IDs, what do you check first?

But the customer still has to add the item to the cart and reach checkout. A correct product page does not tell you what the next steps will show.

Imagine the page says $40 while the cart still shows the old price. The customer notices the difference just as they are ready to order.

Follow the price through the journey

Open the public site on your phone, without signing in as an administrator. Find the product, add it to the cart and go to checkout.

Check the item price at each step. Then look at the final total: shipping, taxes or other fees may make it different from the item price. The key is whether the customer can see what makes up the total.

You don't need to pay to check the displayed price. If you must place a test order to check a later step, clearly mark it as a test and make sure nobody starts fulfilling it.

Keep the result with your launch plan

A note saying “price checked” can be easy to misunderstand. Write down which product you checked, what you saw in the cart and checkout, and anything that still needs fixing.

Launch Control Desk helps keep launch tasks, owners and results together in one local workspace. You do the checks yourself; the tool records the work. The package includes a RU/EN app, examples and instructions. Extract the archive and open index.html.

It costs RUB 1,190 as a one-time purchase. Get Launch Control Desk.

I'm Daniil Kornilov, author of Kornilov Tools. Follow this blog for practical website checks and tools for everyday work.

When did you last go through checkout on your own site?

Before calling the job done, follow one inquiry to the person who will answer it.

Test the whole conversation

For a website that delivers inquiries by email, try this:

1. Open the public site on a phone, signed out of the admin account.
2. Send a clearly marked test inquiry using an email address you control.
3. Find that exact message in the intended inbox.
4. Check that its text and reply address survived.
5. Reply and check that your test address receives the answer.

This gives you something specific to record: the inquiry arrived, and the recipient could answer it.

If the message is missing, check the form service's record, the destination address and the spam folder. Find where the route stopped before changing things at random.

One successful message does not guarantee future delivery. Repeat the check when you change the form or its destination, and keep a way to notice failures after launch.

Keep the result beside the task

“Contact form checked” is easy to misunderstand later.

“Test inquiry received in the support inbox; reply received at the test address” tells the next person what actually happened. Add the date, site version and person who checked it to your private release notes.

I'm Daniil Kornilov, the author of Kornilov Tools. Launch Control Desk helps organize checks, owners, results and remaining launch risks in one local RU/EN workspace. You perform the checks yourself; the app records the outcomes.

The package includes the app, examples and instructions. Extract the archive, open index.html and export separate JSON backups of your plan.

RUB 1,190 for a one-time purchase, with no mandatory subscription inside the app. Buy Launch Control Desk.

Follow this blog for simple website checks and practical tools for small projects.

When did you last send a message through your own contact form?

You ask an assistant: “Make this page better.”

It changes the colors, rewrites the headline and moves several sections. Maybe those changes look fine. They still make a small fix harder to review.

The request left the size of the job open.

Name the problem and the boundary

Try this instead:

On a 360px-wide screen, make the contact button easy to find in the first section. Change only its size and spacing. Keep the text, colors and desktop layout. Show me what changed before doing anything else.

Now you have something concrete to review. Open the page at that width. Find the button. Check that it does not cause sideways scrolling. Compare the desktop layout.

This is a clearer assignment, not a guarantee about how a model will behave. Inspect what it actually changed.

If the allowed change cannot solve the problem, ask for an explanation before making the job bigger.

Write the finish line first

Before sending a request, finish this sentence:

I will know this is done when…

For the button: “I can find it in the first section on a phone, and the rest of the page still looks the same.”

For an article: “The introduction is shorter, the jargon is gone and one useful example remains.”

For a spreadsheet: “The totals match the supplied example, and the original data is preserved.”

The point is to choose an outcome you can check. “Better” alone does not tell you when to stop.

Keep client changes visible too

When a client requests another change, keep the original agreement beside the new request. That makes the difference easier to discuss before work starts.

I'm Daniil Kornilov, the author of Kornilov Tools. Scope Change Desk helps record project scope, revision rounds and requests for additional work. It includes a local RU/EN app, an Excel workbook, examples and instructions. Extract the archive and open index.html; export separate JSON backups of your project.

RUB 790 for a one-time purchase. Buy Scope Change Desk.

Follow this blog for plain-language breakdowns of practical work problems and useful tools.

What vague request would you like to stop receiving?

That result should make a green test badge feel less reassuring.

Here is a small experiment you can run in Node.js. The business rule is explicit: shipping costs 500 cents below a subtotal of 5,000 cents, and is free at or above that threshold. All inputs in the experiment are valid nonnegative integer subtotals.

A plausible test with a large blind spot

import assert from "node:assert/strict";

// Amounts are integer cents. This example uses valid subtotals only.
const variants = {
  reference: s => s >= 5000 ? 0 : 500,
  wrongBoundary: s => s > 5000 ? 0 : 500,
  alwaysFree: s => 0,
  wrongFee: s => s >= 5000 ? 0 : 5000
};

for (const [name, shipping] of Object.entries(variants)) {
  assert.equal(shipping(6000), 0);
  console.log(name, "PASS");
}

The output is four passes. The correct implementation passes. So do three incorrect ones: a threshold off by one, free shipping for every order, and a fee ten times too large below the threshold.

Nothing is wrong with assert.equal. The test asks only about an order that qualifies for free shipping. All four implementations answer that particular question correctly.

Ask the test to distinguish the alternatives

Keep the 6,000-cent case, then add observations at the boundary and immediately below it:

assert.equal(shipping(4999), 500);
assert.equal(shipping(5000), 0);
assert.equal(shipping(6000), 0);

Running those assertions against the four implementations produces this matrix:

These are results from the local example, not measurements of a model or a production checkout. The three-case check detects these three changes. It does not establish complete input validation, tax correctness, currency handling or checkout reliability.

The same assistant can miss the rule twice

When a coding assistant proposes both an implementation and its tests, inspect which examples it chose. If both artifacts share an omitted boundary, agreement between them tells you little about that boundary.

There is no model comparison hidden in this experiment. A person can write the same weak test. The useful question is whether the test can reject a believable wrong implementation.

A more useful review request is:

Name three plausible mistakes in this rule. Change the implementation to each one separately, then show which assertion fails.

That asks for evidence of discrimination. “Add more tests” can produce a longer suite of the same happy path.

You can start without another test framework

The deliberate changes here are a small manual exercise. Automated mutation testing applies this idea more broadly. Stryker's documentation explains the difference between changes that tests detect and changes that survive.

Start with a consequential rule whose expected outcomes you can explain independently: a shipping threshold, a permission decision or an import rejection. Keep the expected behavior separate from the implementation under review.

If no one can explain why an expected value is correct, asking another model to repeat it does not settle the requirement.

Turn the example into a release check

Write down the business rule, fixtures, expected outcomes and observed result before release. Keep the owner and unresolved gaps beside the result.

I'm Daniil Kornilov, the author of Kornilov Tools. Launch Control Desk is my local RU/EN browser tool for organizing release checks, risks, owners and supporting evidence. It does not execute the tests; you record the outcomes of checks you perform. Extract the ZIP and open index.html, and export separate JSON backups of your work.

RUB 1,190 for a one-time purchase. No mandatory subscription inside the app.

Buy Launch Control Desk.

Follow this blog for reproducible engineering examples and practical tools for small projects.

That change is useful to think about when designing a dashboard API. Start with the question the screen must answer, then decide what data the client should receive.

Define the decision before the payload

Consider a fictional dashboard for a small project. Its owner wants to compare interest before and after a release. A useful product brief would state the comparison window, date resolution and acceptable delay before a new observation appears.

It should also say what the chart does not prove. A rise in interest is not evidence of paid demand, and an aggregate chart cannot explain why an individual person acted. Those are different questions requiring different evidence.

Review a response as a contract

Before implementing a new endpoint, I would ask the team to approve three example responses: an ordinary period, an empty period and a period where collection failed. The interface should not silently draw the same zero-height line for all three.

Then inspect the client's responsibilities. Does it have enough context to label the time window? Can it tell a complete result from a partial one? Does the screen explain what the count represents? These are product questions even when their answers appear in a JSON schema.

Turn the design into a reviewable experiment

Use a fictional fixture with a release date and known observations. Ask a reviewer to explain the chart without reading the implementation. If they mistake an unavailable period for no activity, change the response or presentation before adding more visual polish.

Keep a short decision note with the intended question, sample response and known gaps. That note gives later changes a useful test: does the new contract still let a reader make the intended comparison? A compact payload is valuable when its meaning survives the trip to the screen.

Consider a small case-study editor. A visitor has written a project description, then clicks “View an example”. If the implementation copies sample text into the same object that autosave uses, the next save can replace the visitor's work with fictional content.

Separate the working draft from the displayed example

In the Kornilov Tools free case editor, the working draft and the current display mode are separate. The display chooses either a newly created fictional example or the working draft. Opening an example does not import it into the working object.

This makes the boundary explicit: viewing an example is a navigation action; replacing work is a different operation. The example is also labelled fictional in exported output.

Treat import as a replacement workflow

A JSON file should be parsed and validated before it becomes the working draft. In this editor, selecting a valid backup opens a confirmation dialog. Continuing first initiates a download of the current draft, then applies the replacement. Cancelling leaves the draft unchanged.

That downloaded copy is a safeguard, not a storage guarantee: the browser can still block a download, and the user needs to keep the file. The interface should make that responsibility understandable.

Preserve unreadable data

A saved string that fails parsing is not an empty draft. The editor keeps the original string available for rescue and blocks ordinary saves while recovery is pending. Otherwise, an innocent input event could replace the only remaining copy with a new blank object.

Storage itself can also fail. A local-only interface should show that saving is unavailable while keeping the visible text available for export.

Describe this as a technical case

The useful portfolio claim is the behaviour, not “improved user experience”. A concrete review scenario is:

1. Write a draft with a recognisable title.
2. Open the fictional example, then return to work.
3. Check that the title remains unchanged.
4. Select malformed JSON and check that it does not replace the draft.
5. Import a valid backup, cancel once, then confirm and inspect the downloaded previous draft.

These are suggested checks for the failure paths, not evidence that every browser or storage condition has been tested. A screenshot of a successful import alone cannot establish all of them.

A strong case study names the state boundary, explains the rejected shortcut, and shows what evidence would establish the claimed behaviour. That gives a reader something more useful than a list of frameworks.

Give the reader a short route through one case: the problem, your role, a technical decision, and something they can inspect. A screenshot explains the interface. A small diagram explains the boundary. A test or reproducible demo supports the result.

For a personal project, say it is a personal project. Explain the constraint you chose: local storage, a small input limit, no server, or a narrow audience. Those choices can lead to a useful discussion even without paying customers.

One detail is worth including: what you intentionally left out and why. “I used one stable ID rather than fuzzy matching because ambiguous matches needed manual review” reveals more judgment than a row of library badges.

Check the case on a phone. Can someone understand the project before following a link? Is the repository easy to find? Does the demo work without your development environment?

Portfolio Case Kit is my local editor for assembling these cases and exporting a standalone portfolio site or GitHub README. You write the project details; the tool handles the structure and export.

See the portfolio kit.