#1 Measure seven times, cut once – or build, test, learn, repeat?

Insider tips on how to realistically approach prototyping and system development from IoT engineers

Welcome to edition #1 of the LMT IoT newsletter! We’re pulling back the curtain on hardware, software, and real-world system development – straight from the engineers in the trenches.

We are the team behind LMT’s Internet of Things solutions, turning smart connectivity into tangible hardware and software systems. Whether you build devices, develop software, or manage tech products, we’re glad you’re here.

Is careful planning better than rapid experimentation? In our first feature, LMT IoT engineers Valters, Reinis, and Rihards explore why “measure seven times, cut once” might be holding your development cycle back, and how building early reveals the blind spots no simulation can catch. Happy reading!

Measure seven times, cut once – or build, test, learn, repeat?

Insider tips on how to realistically approach prototyping and system development from IoT engineers

There’s a proverb from this part of the world that goes something like this: “Measure seven times and cut once.” It’s pretty good general advice about being careful before making a decision that can’t be easily reversed. Plan properly, check your work, and only when you’re confident – take the leap.But in engineering, this advice has one important limitation: it assumes you already know what needs to be measured.

Sometimes, building the first version is the only way to discover what measurements you’re missing.

“You can only measure what you know,” says Valters Skrastiņš, Hardware Technical Manager at LMT IoT. “You cannot measure what you don’t know. You may not even know that something exists or that you should be measuring it.”

At LMT IoT, we’re in a constant cycle of R&D, testing, iterating, launching, and repeating. As such, our team of engineers has decades of experience in new product development. We spoke to several of our teammates to explore what the best advice is when it comes to developing IoT products – or in fact, any product you want to put out into the world.

The limits of planning

Engineers can calculate, simulate, and review a design from several angles. On paper, everything may appear to have been considered. Then you get to the physical version. “Often, you design something and think that everything’s there, everything has been measured and everything has been considered,” Valters explains. “Then you manufacture it and realise: ‘Ah, this exists too.’”

This does not necessarily mean the design was checked poorly. Some realities only reveal themselves once the individual parts have been put together and are asked to operate as a system.

“No matter what you do, that first version will still contain mistakes,” he says. “The sooner you make it, the sooner you see them. And the sooner you can solve them and improve the design.”

For Valters, pursuing certainty before building can become a never-ending story. He favours shorter development cycles. Each version turns another unknown problem into a known one.

The PCB tells you what the model cannot

For Reinis Valters Kobitjevs, Application Engineer at LMT IoT, this principle is visible in PCB (printed circuit board) development. “When we make boards, we iterate through the process,” he explains. “You create the simplest version, see what’s wrong with it, what could be improved or added, and then continue from there.”

Modelling and calculation remain essential, but they’re unable to represent every interaction between real components. “It’s still hardware, and the components are complex enough that you can’t fully simulate or measure everything,” Reinis says. “Only when you build the board and begin testing it do you understand the problems it has – and also the things it does well.”

A simulation shows how a model behaves. A prototype reveals how the actual system behaves.

“If you keep trying to create the ideal board from the beginning, making one board can take half a year,” Reinis says. “It simply takes too long.”

The choice is not between thinking and blindly experimenting. An early iteration answers questions that calculations alone cannot.

Context matters

When asked to choose between the two approaches, Rihards Balašs, Application Engineer at LMT IoT, joked that he could answer with a GIF:

His longer answer – it depends on the situation. “Sometimes, you simply can’t understand everything at once,” he says. He sees this in 3D design. Even after careful modelling, you can’t always be certain that every part will fit. A 3D printer lets you build, assemble, and identify what needs to change.

“You build it, put everything together, discover that something’s still not quite right, and then try again,” Rihards explains.

Here, iteration is part of the design process. The prototype is inexpensive, changes remain possible, and each attempt provides new information. Rihards jokes that the same applies to PCB development: the third version is often the one that finally works properly. But the equation changes when mistakes become more expensive.

Rihards gives the example of building a cabinet for a precisely defined space. Although it’s a simple thing to do, if you have one board to cut to a very specific size, you’ll probably measure more than once, just to be sure. Otherwise, you may be driving back to the hardware store.

The difference is the cost and reversibility of the next decision. When a potential mistake is large or expensive, Rihards believes you shouldmeasure seven times before cutting. For everything else, iterate as much as possible – without letting perfectionism stop progress.

Perhaps the saying is just incomplete

“Measure seven times and cut once” is not bad engineering advice or life advice in general. Preparation prevents avoidable mistakes, especially when a decision is expensive or difficult to reverse.

But measuring and iterating are not opposites. Early in development, a prototype may itself be a measuring instrument. It exposes assumptions the team did not realise it was making. As the design matures and changes become costlier, the balance can shift towards deeper verification.

The first version does not need to be perfect. It needs to teach the team something useful. Perhaps the engineering version of the saying should be:

Measure what you know. Build to discover what you don’t. Then measure again.