A small team has more good ideas than it has hours. That's not a complaint; it's the actual constraint that shapes how we decide what gets built next, what gets shelved for later, and what only makes sense with a client or research partner attached from the start. This is roughly how that decision actually gets made, not the idealised version.
The first filter: does someone need this now, or might someone want it eventually
Ideas that come from a real, current problem, a farmer describing exactly what's failing them, a school asking for a specific capability, a partner with a defined use case, get prioritised over ideas that start from "this technology is interesting, someone will probably want it." Both kinds of ideas are legitimate starting points, but the first kind comes with a built-in way to know if you've actually solved the problem: the person who described it can tell you. The second kind can consume real engineering time before you find out whether the assumed need was real.
This doesn't mean we only build to order. It means an idea without a specific person or use case attached to it goes into a smaller, lower-priority bucket than one with a real, current problem behind it.
The second filter: can we actually validate it cheaply first
Before committing meaningful engineering time to a new direction, we look for the cheapest possible way to learn whether the core idea holds up: a rough bench prototype rather than a field-ready unit, a small pilot with one willing site rather than a full rollout, existing off-the-shelf components stood in temporarily for something we'd eventually design custom. The goal at this stage isn't a good product. It's a fast, honest answer to "does this actually work the way we think it does," because that answer changes the shape of everything that follows.
The third filter: does this fit what we're actually good at, or does it need a partner
Not every good idea fits inside a small team's existing skills, and pretending otherwise wastes time relearning things a partner already knows. Where an idea needs expertise clearly outside our own (a specific scientific domain, manufacturing scale we don't have, distribution we can't reach alone), the decision isn't "learn it from scratch" by default. It's an honest assessment of whether this is worth building the capability in-house, or whether the right move is finding the right partner and focusing our own effort on the part we're actually positioned to do well.
What gets shelved, and why that's not a failure
A meaningful share of ideas that pass the first two filters still get shelved, usually because the team's current commitments don't leave room, not because the idea was bad. We keep a running list rather than discarding these, because a shelved idea often becomes viable again later: a client's use case makes the validation step unnecessary because it's already been done implicitly, or a partner appears who covers exactly the gap that made the idea impractical alone.
Why we're honest about this being resource-constrained
It would be easy to write this post as if prioritisation is purely about elegant strategy. In practice, a small team's biggest constraint is genuinely just hours, and the discipline is less about being clever and more about being honest with ourselves about what we can actually finish well in the time we have, rather than starting five things and finishing none of them properly. Clients and partners are usually better served by a team that says no to the wrong project than one that says yes to everything and delivers slowly.
If you have a project that needs hardware or IoT R&D and want to know honestly whether it's something we're positioned to build well or something better suited to a different partner, get in touch and we'll tell you which. You can also see how we take hardware from prototype to the field.
