Systems Engineering Consultancy

Give us the problem nobody can crack.

In a few weeks you get a working prototype, a demo you can put in front of customers, and a design you can actually ship — built on the right parts for the job, not the newest ones. Wavelet Solutions is a small, senior consultancy for RF, low-power, and embedded problems that have already beaten the obvious answers.

Start a conversation → How a proof of concept works →
Experience 25+ years defense, aerospace, industrial, embedded, RF
Focus RF/DSP, low-power embedded, SCADA, proof of concept
Practice Small. Senior. Hands-on.
A Morlet wavelet drawn at nine successive dilations, stacked as overlapping ridges.

Proof of concept

A prototype in weeks. A direction you can ship.

Most of what we do starts the same way: a link that will not close, a battery that will not last, a sensor nobody has managed to read, a concept that needs to exist before the money does. One senior engineer takes it, goes quiet for a few weeks, and comes back with something that works.

You bring

The problem, as it is.

A board that does not work yet, a range that has to be met, a power budget that has to hold, a demo date. You do not need a specification. You need someone who has written enough of them to know what yours would say.

You get

Working hardware, a demo, a design.

A prototype you can put on a bench and a demo you can put in front of a customer. Behind it, measured numbers, the trade-offs that were made and why, and a design you can carry straight into a product without throwing the prototype away.

Built on

The right parts, not the newest ones.

Leading edge is not the same as latest. The prototype is built on the least machine that meets the spec, so the numbers it produces are the numbers the product will produce. What you demo is what you ship.

Typically four to twelve weeks · one engineer, end to end · fixed scope, delivered remotely · RF, low-power, sensing, embedded

Most project failures trace back to one of three things: requirements that were never clearly defined, architecture that was wrong from the start, or a team with no one who could own the full technical picture. Fix those three things and projects move.

From the Wavelet engagement playbook

What we work on

Recognizable situations.

Most engagements start when a working engineering team hits a problem that doesn’t fit any one specialist’s scope, or hits it before there is a team at all. Here are the shapes those problems tend to take.

Illustrative chart showing the estimated scope of a problem as a band that starts very wide at the first conversation and converges toward the actual scope as assessment and requirements work proceeds.
Fig. 1 Illustrative. At the first conversation the honest range on what a problem will take is enormous — wide enough that any number quoted inside it is a guess wearing a suit. Closing that band is work, and it is the first work we do. You are not expected to arrive with a specification; producing one is the deliverable that makes everything after it estimable.
The operating assumption

Nobody calls a small consultancy about a problem that was easy. By the time we hear about it, the obvious things have already been tried — so the first job is almost never to fix it, it is to find out what it actually is.

No. 01

A concept that needs proof before the money arrives.

The link budget closes on paper. The battery math works in a spreadsheet. The customer, the board, or the investor wants to see it run, and the date is closer than the team.

How we respond

A proof of concept built by one engineer in weeks: working radio, sensor, or controller on the bench, measured against the numbers that were promised, with a design that carries straight into the product. The demo is the deliverable, and it is not disposable.

No. 02

Legacy SCADA running on borrowed time.

The RTUs still work. The master station runs on Windows XP. The vendor is gone. The integrator retired. You know it needs upgrading, but you can’t afford downtime and can’t risk breaking what has been reliable for years.

How we respond

Phased migrations that preserve field equipment while modernizing the master station. New network architecture, modern HMI, secure remote access — executed while the system stays operational.

No. 03

A software project that has gone off the rails.

Budget blown, timeline gone, team spinning. The architecture was wrong and the requirements were never properly defined. The original approach is not going to get you where you need to be.

How we respond

An honest technical assessment, then a recovery path with real requirements and realistic scope. We tell you specifically which components need to be rebuilt and why.

No. 04

Mysterious failures nobody can diagnose.

Something is failing intermittently. Maybe it’s timing, maybe RF interference, maybe a protocol edge case. Three contractors have looked at it. None of them figured it out. The pressure to fix it keeps building.

How we respond

Oscilloscopes, protocol analyzers, and actual diagnostic skill. Schematics read, signals traced, timing analyzed, root causes identified. Permanent fixes, not workarounds.

Three more recognizable shapes —

No. 05

A technical leadership gap on a critical program.

Your lead engineer left, or you never had one. There’s a project manager but nobody who can make technical decisions with confidence. The team is capable but directionless, and the schedule won’t wait.

How we respond

We step in as the technical lead. Architecture defined, blocking decisions resolved, engineering standards set, the team moving. Present and engaged, not a consultant who disappears between meetings.

No. 06

Custom hardware with no source code.

Your controller works perfectly but the original programmer is long gone. You need new features or modern connectivity. Everyone says it’s impossible without the original source.

How we respond

We reverse-engineer embedded systems and recreate firmware from scratch. Schematics welcome but not required. Modern connectivity can be added cleanly once the existing behavior is understood.

No. 07

Integration between systems that don’t talk.

Three vendors claim compatibility. None of them work together. None of them will take responsibility for making it work.

How we respond

We become the integration authority. Protocol specs, gateway development, communications debugging. Modbus to DNP3, proprietary to OPC UA — we’ve bridged all of them.

Illustrative chart comparing two delivery paths: one showing fast early progress that stalls in rework and finishes late, and one showing little early progress that then rises steeply and finishes earlier.
Fig. 2 Illustrative. Skipping analysis buys visible progress in the first few weeks and pays it back with interest when the thing nobody characterized surfaces. The front-loaded path looks slower right up until it does not — and it is why the assessment phase is not negotiable.
Right-skewed latency distribution with the median and the 99.9th percentile marked, and the ratio between them called out.
Fig. 1 An illustrative latency distribution — not measured data from any system. The shape is the point: the median tells you almost nothing, and the distance out to the tail is what actually sizes a buffer. Characterizing that distance is the difference between “it worked when we ran it” and a bound you can defend.

What we don’t do

Knowing what we’re not.

The practice is small and the focus is deliberate. There are categories of work that look adjacent on paper but aren’t what we do well, and we’re direct about that. If your problem falls in one of these areas, we’ll point you to a better fit.

Illustrative plot of cost against capability, with a superlinear cost curve, a marked requirement line, and three design points: under-scoped, right-sized, and a far more capable reflex answer costing several times more.
Fig. 3 Illustrative. Cost does not rise in step with capability, it rises faster — so capability past the line is the expensive kind of free. The reflex answer to almost any signal problem is one large part that could do far more than the job needs; the right answer is usually the least machine that meets the actual spec, and then stopping. Both outer points are failures. Only one of them looks like one on a datasheet.

Pure web/mobile app development.

If your project is fundamentally a CRUD web app or consumer mobile product, our depth doesn’t earn its keep. Hire a product-focused shop.

Staff augmentation by the hour.

We work as the engineering owner, not as one developer in a larger team. If you need a body to fill a seat, we’re the wrong call.

Long-term operations or managed services.

Engagements have a delivery point. Once your team is trained and the system is documented, we hand off and step away. We don’t run your systems for you on retainer.

Generic IT consulting.

Network buildouts, ERP rollouts, helpdesk strategy — not us. We work where the engineering depth matters, not where it’s a category.

Engineering North Star

How we think, written down.

The systems engineering principles we practice on every engagement — first-principles thinking, requirements discipline, what makes architecture survive contact with reality. Read it before you talk to us; it’ll tell you whether we’re a fit faster than any sales call.

No signup. No paywall. Free.

Read the guide →

Start a conversation

Tell us about your situation.

The first conversation is short, focused, and free. Bring the problem as it stands; we’ll tell you whether it is a fit, what a proof of concept would look like if it is, and who to call if it isn’t. Either way, you’ll leave with a clearer picture than you came in with.

Start a conversation → See capabilities →