Why I Built a Decking Calculator That Shows Its Working

nagehan zarif — Tue, 03 Nov 2026 18:51:06 +0000

Why I Built a Decking Calculator That Shows Its Working

Estimating materials for a decking project sounds simple until you start dealing with board dimensions, spacing, waste percentages, subframes, fixings, and incomplete supplier pricing.

A basic calculator might multiply length by width and return a square metre figure. Unfortunately, that doesn't tell you how many boards you should buy, how many joists you need, or whether your estimated budget is actually complete.

While developing Teosad, a decking planning and comparison platform for the UK and Australia, I explored how to make these calculations more transparent.

The goal is simple: users should understand where the numbers come from, not just see a final result.

In this article, I'll walk through a simplified JavaScript implementation of the core estimation logic.

1. The Inputs We Need

For a rectangular decking project, we'll use:

Deck length and width in metres
Board length in metres
Board width in millimetres
Gap between adjacent boards
Joist centre spacing
Waste allowance percentage
Optional board pricing

We'll assume boards run along the deck length, while joists run perpendicular to them.

This is an illustrative estimator, not a complete structural design or cutting optimisation system.

2. Calculating the Number of Board Rows

The first calculation determines how many rows of decking boards are needed to cover the width.

We must account for the gap between boards.

function calculateRows(deckWidthMm, boardWidthMm, gapMm) {
  if (
    deckWidthMm <= 0 ||
    boardWidthMm <= 0 ||
    gapMm < 0
  ) {
    throw new Error("Invalid dimensions");
  }

  return Math.ceil(
    (deckWidthMm + gapMm) /
    (boardWidthMm + gapMm)
  );
}

const rows = calculateRows(3000, 145, 5);

console.log(rows); // 21

For a deck that is 3 metres wide, using 145 mm boards with a 5 mm gap, the estimated number of rows is 21.

The calculation rounds up because you cannot leave a section of the deck uncovered.

The final row may require a rip cut, and minimum permitted board widths should be checked against the manufacturer's installation instructions.

3. Estimating Boards and Waste

Now let's calculate the total linear metres of decking needed.

const deckLength = 4;
const rows = 21;
const boardLength = 3.6;
const wastePercent = 10;

const linearMetres = rows * deckLength;

const boardsBeforeWaste = Math.ceil(
  linearMetres / boardLength
);

const boardsWithWaste = Math.ceil(
  linearMetres *
  (1 + wastePercent / 100) /
  boardLength
);

console.log({
  linearMetres,
  boardsBeforeWaste,
  boardsWithWaste
});

Output:

{
  "linearMetres": 84,
  "boardsBeforeWaste": 24,
  "boardsWithWaste": 26
}

However, there's an important limitation.

A 4-metre run is longer than a 3.6-metre board. The theoretical 26-board estimate assumes cuts can be reused efficiently between rows.

If offcuts cannot be reused, the project may require substantially more material. Every board joint must also be supported according to the manufacturer's instructions.

A reliable calculator should flag this issue instead of silently assuming perfect material utilisation.

For diagonal layouts, complex shapes, stairs, or obstacles, the waste allowance may need to be higher.

4. Calculating Joist Requirements

Joist spacing is another important input.

For our simplified rectangular layout:

function calculateJoists(deckLengthMm, spacingMm) {
  if (deckLengthMm <= 0 || spacingMm <= 0) {
    throw new Error("Invalid joist dimensions");
  }

  return Math.ceil(deckLengthMm / spacingMm) + 1;
}

const joists = calculateJoists(4000, 400);

console.log(joists); // 11

This produces an estimate of 11 joist lines.

The actual design may require additional joists for board joints, edges, stairs or other structural details. The spacing must come from the relevant manufacturer's installation guide, not an arbitrary default.

5. Why Missing Prices Should Never Become Zero

This is one of the most important lessons when designing a cost estimator.

Suppose we know the board price but have no prices for joists, supports or fixings.

A calculator that quietly replaces missing prices with zero will produce a misleading total.

Instead, we can represent missing prices explicitly:

function calculateCost(quantity, unitPrice) {
  if (
    unitPrice === null ||
    unitPrice === undefined
  ) {
    return null;
  }

  if (quantity < 0 || unitPrice < 0) {
    throw new Error("Invalid price or quantity");
  }

  return quantity * unitPrice;
}

const boardCost = calculateCost(26, 35);
const joistCost = calculateCost(33, null);

const isPartial = joistCost === null;

console.log({
  boardCost,
  joistCost,
  status: isPartial ? "Partial" : "Complete"
});

Output:

{
  "boardCost": 910,
  "joistCost": null,
  "status": "Partial"
}

The result is not a complete project quotation.

This approach encourages users to enter real supplier quotes and helps prevent false confidence in an incomplete budget.

For production use, I'd also recommend recording the currency, price date, tax treatment and delivery assumptions.

6. Making Calculations Explainable

A useful calculator shouldn't simply display:

Estimated materials: 26 boards

It should also show:

Deck area: 12 m²
Board rows: 21
Linear metres required: 84 m
Boards before waste: 24
Estimated boards with 10% waste: 26
Joist lines: 11
Warning: board joints and offcut reuse require verification

This is especially important when a user needs to compare different board lengths or material systems.

By exposing the formulas, the calculator becomes both a planning tool and an educational resource.

7. Applying This Approach to Teosad

These ideas are part of the approach behind Teosad's decking calculator.

The platform provides decking material comparisons, calculation tools, buying guides and supplier information for UK and Australian projects.

One design principle is to distinguish between verified product information, estimated material quantities and user-supplied prices.

A missing specification should remain visibly unavailable. A missing price should not be treated as free.

The JavaScript above is a simplified teaching example, not a reproduction of Teosad's production source code.

Final Thoughts

Good calculators do more than produce answers. They explain assumptions, expose limitations and make uncertainty visible.

Whether you're developing a construction estimator, a shipping calculator, a financial planning tool or a pricing application, the same principles apply:

Validate the inputs.
Keep units consistent.
Make formulas inspectable.
Handle missing data explicitly.
Explain where estimates may differ from real-world results.

Sometimes the most useful feature isn't another calculation. It's explaining why the calculation should be trusted — and when it shouldn't.

This article was prepared with AI writing assistance and reviewed against the described calculator behaviour. Teosad is my project. The code examples are illustrative and should be adapted and tested before production use.

DEV Community: nagehan zarif

Why I Built a Decking Calculator That Shows Its Working