DEV Community: Mohamed Ghanem

Three small browser tools, three different correctness problems

Mohamed Ghanem — Thu, 22 Oct 2026 16:12:58 +0000

A calculator can look polished and still be wrong. An inventory estimate can use the right formula against the wrong stock figure. A worksheet can print a neat answer key that belongs to a different set of questions.

Wizekin's three new browser tools made these differences concrete. Here are the implementation decisions behind a handmade pricing calculator, an inventory reorder calculator, and an arithmetic worksheet generator.

1. State what a percentage is a percentage of

For handmade pricing, “add 30% profit” is ambiguous. A markup is measured against cost. A margin is measured against selling price.

For a unit cost of 7.30:

const markupPrice = 7.30 * 1.30;       // 9.49
const marginPrice = 7.30 / (1 - 0.30); // about 10.43

Selling fees introduce another dependency on the final price. If the channel takes 5% of the selling price plus 0.30 per item, and the target margin is 30%, solve for price:

function sellingPrice(unitCost, fixedFee, margin, feeRate) {
  const denominator = 1 - margin - feeRate;
  if (denominator <= 0) {
    throw new Error('Margin plus percentage fee must be below 100%.');
  }
  return (unitCost + fixedFee) / denominator;
}

sellingPrice(7.30, 0.30, 0.30, 0.05); // 11.692307...

The function takes fractions, not whole percentage numbers. The UI accepts 30 and 5, then converts them. That boundary needs to be explicit.

The fixed-fee assumption matters too: one item per transaction. A multi-item order needs its order-level fee allocated across the items. Shipping, tax, failed output, and material allowance also need named assumptions rather than hidden defaults.

The free CraftCost Studio includes a complete batch example and separates labor cost from the profit remaining after the entered costs.

2. Use the right stock figure

A simple reorder point is average daily demand multiplied by supplier lead time, plus safety stock. But comparing it only with stock on the shelf can ignore an incoming shipment or reserved units.

const reorderPoint = dailyDemand * leadDays + safetyStock;
const inventoryPosition = onHand + onOrder - allocated;
const shouldReorder = inventoryPosition <= reorderPoint;

With demand of four units per day, seven lead days, and ten safety units, the reorder point is 38. If there are 25 units on hand, ten incoming, and five allocated, position is 30.

An order quantity needs another decision: the target coverage. Seven extra days gives a target of 4 * (7 + 7) + 10, or 66. This model suggests 36 units when the reorder condition is met.

The useful tests include equality at the reorder threshold, zero demand, and allocations exceeding on-hand stock. Zero demand should produce an explicit “undefined” stock-cover result, not an infinite-looking number that reads like a recommendation.

StockSimple Studio exposes each assumption. It is a planning calculator, not a demand forecast or an accounting valuation service.

3. Generate the question and answer together

For exact-division practice, rejection-sampling random dividends until they happen to divide evenly is unnecessary. Choose a nonzero divisor and a quotient, then construct the dividend:

const divisor = 8;
const quotient = 10;
const dividend = divisor * quotient; // 80
const question = { dividend, divisor, answer: quotient };

The range now describes divisor and quotient. The dividend can be larger, which the UI needs to explain.

Each question object contains its answer. Both the worksheet and the answer page render from the same objects. A seeded random generator makes a sheet reproducible from its settings, while changing the seed produces another sequence. Repeated questions can still occur; deterministic does not mean unique.

LessonSheet Studio uses this approach for printable arithmetic practice and separate answer pages. It does not collect student records or claim curriculum certification.

Keep the calculations independent of the page

All three tools put calculation functions in a shared module that Node can test without loading a browser. Useful assertions check identities: the calculated craft profit has the intended margin; inventory position reconciles; every exact-division question satisfies dividend === divisor * answer.

Browser testing then covers the things those assertions cannot: reset controls, labels, saved-state behavior, and narrow-screen layouts. In this release, browser testing caught a reset control shadowing form.reset, and a note field that was accidentally required. Passing arithmetic tests did not catch either issue.

Maker disclosure: these are Wizekin tools, developed with AI assistance. The public tools are free. Separate offline workspace editions have been prepared, but their paid listings are not live at publication time. There are no traffic, income, or maintenance guarantees.

How I Break Down a Freelance Website Quote Before Naming a Price

Mohamed Ghanem — Thu, 22 Oct 2026 11:30:55 +0000

How I Break Down a Freelance Website Quote Before Naming a Price

It's surprisingly easy to quote a freelance website by looking at its page count and multiplying by a number you found online. The problem: two five-page websites can represent very different amounts of work.

A brochure site with client-provided copy isn't the same project as a site with custom forms, integrations, content migration and an uncertain approval process.

A better starting point is to estimate the work you actually intend to deliver and put the assumptions in writing.

1. Turn the vague request into a scope

Before naming a price, write down what "a website" actually means.

For a small brochure website, that might include:

Five responsive pages with agreed layouts.
The client supplies final copy and images.
One contact form with basic validation.
Testing in a small, documented set of target browsers.
Two rounds of revisions on the approved design.
Launch to an agreed hosting environment.

Then write down what's not included: logo design, copywriting, monthly maintenance, paid plugins and new pages after scope approval.

This is not needless paperwork. It is how you distinguish an estimate for specific work from a promise to do anything a client later imagines.

2. Estimate hours, not just pages

Here's an illustrative task estimate:

Work	Hours
Five pages, 3 hours per page	15
Discovery and project setup	4
Testing and launch	3
Expected revision work	3
Estimated total	25

The 25 hours are an example, not a standard workload. A developer using reusable components may take less time. A custom design with complex interactions may take much longer.

Choose an internal hourly planning rate that covers your earning goals and real business costs. For this example only, use $45/hour.

Labor estimate: 25 × $45 = $1,125.

3. Separate direct costs from the price of your time

Suppose this project also needs $75 in project-specific expenses.

Now the base estimate is:

Labor: $1,125
Direct expenses: $75
Base: $1,200

If you add a 10% contingency to address foreseeable estimation uncertainty, that's another $120, bringing the illustrative total to $1,320 before any applicable taxes.

A contingency isn't guaranteed profit, and it shouldn't silently substitute for a clear scope. Your agreement should explain what you're actually charging and delivering.

4. Make the payment terms concrete

An estimated project price isn't yet a usable quote.

Say you agree on a 30% upfront deposit:

Total project price: $1,320
Deposit on acceptance: $396
Remaining balance: $924

The deposit is part of the $1,320 total. It isn't a surcharge. Also spell out when the balance becomes due and what happens if the project is delayed or canceled.

A one-line quote such as "website — $1,320" leaves too many questions unanswered.

5. Write a change-request rule before you need one

Imagine the project is approved and the client asks for two additional pages.

Instead of treating the new pages as automatically included, use a simple process:

Describe the requested change.
Estimate the additional time, cost and schedule impact.
Ask for agreement on the change.
Begin the extra work after approval.

This is easier for both parties when the original scope specified five pages and a finite number of revision rounds.

6. A tiny calculator in JavaScript

The arithmetic can be expressed as a pure function:

function estimateWebsite({
  pages, hoursPerPage, setupHours, testingHours,
  revisionHours, hourlyRate, expenses,
  contingencyPct, depositPct
}) {
  const hours =
    pages * hoursPerPage + setupHours + testingHours + revisionHours;
  const labor = hours * hourlyRate;
  const base = labor + expenses;
  const total = base * (1 + contingencyPct / 100);
  const deposit = total * depositPct / 100;

  return { hours, labor, total, deposit, balance: total - deposit };
}

// Illustrative result:
// 25 hours, $1,125 labor, $1,320 total,
// $396 deposit, $924 remaining.

In a real application, also validate every input, handle currency formatting and distinguish fixed fees from percentages. Taxes, if applicable, need to be treated according to the actual agreement and local requirements.

7. Before you send the quote

I would check these questions:

Can the client verify what's included and excluded?
Are the assumptions about content, access and approvals clear?
Have you included testing, meetings and revision time?
Is the change-request process explicit?
Does the payment schedule describe the full agreed price?
Have you considered whether an hourly agreement with a budget cap would suit uncertain work better?

If you want to experiment with your own assumptions, I built a free website project pricing calculator. It estimates hours, labor, expenses, contingency, taxes if applicable and deposits in the browser without signup.

Disclosure: I'm the maker of ClearQuote Studio, which hosts the free calculator and an optional paid quote/invoice toolkit. This post is educational, and the rates are illustrative—not a claim about typical web-development prices.

Question for other freelancers: Which part of scoping a website most often causes you to underestimate the work?