Know whether it's buildable — and what it will cost — before you commit capital
A feasibility study is a structured engineering investigation that answers whether a proposed system can be built, at what cost, with what risks, and by which of the viable approaches. It removes decision-by-optimism: projects green-lit on a vendor's brochure and a hopeful spreadsheet, whose real constraints surface only after the money is committed.
Willowark runs these as engineering, not literature review. We decompose the concept into its claims, sort them into settled, calculable, and genuinely uncertain, and spend the study's budget on the uncertain ones — with first-principles analysis, vendor and component research, and small targeted experiments where paper cannot settle the question. The output is a recommendation you can defend to a board, a bank, or your own engineering team.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The method adapts to the question. Physics and throughput claims get calculated: cycle-time budgets, thermal loads, bandwidth, power. Technology claims get benchmarked: if the concept depends on a sensor resolving a feature or a model hitting an accuracy bar, we test that specific claim on representative samples rather than quoting a datasheet. Cost claims get built bottom-up, with quotes for the long-lead and high-uncertainty items and explicit ranges elsewhere. Every alternative approach considered gets the same scrutiny, so the recommendation is comparative, not advocacy for the first idea.
The final report is written to be acted on: a feasibility verdict with confidence levels, cost and schedule ranges with their driving assumptions visible, a ranked risk register with mitigations, and a recommended path — including, where honesty requires it, the recommendation not to proceed. Study findings flow directly into the next phase, so if you do proceed, the requirements and risk register are already drafted.
The study is framed around the decision it has to support, not around the technology. A board choosing between funding and shelving needs a different level of certainty than a product team deciding which of two approaches to prototype, and the study's depth is set accordingly. For each uncertain claim, we define the cheapest test that would move it into the settled column: a calculation, a phone call to a supplier with a specific question, a half-day experiment on a borrowed sample. Those tests are planned in advance with their pass criteria, so the study produces answers rather than a longer list of things to worry about.
A study that changes the plan has done its job, whether it recommends proceeding, proceeding differently, or stopping. Frequently the useful result is a hybrid — the concept is feasible, but only with a relaxed tolerance, a different sensing approach, or a phased rollout — and the report is explicit about which constraint drove that. The report, the analysis, any experimental data, and the cost model are delivered in editable form and are yours to take to any builder or investor. If the recommendation is to proceed, the risk register and requirements draft carry straight into architecture, a proof of concept, or a prototype without being rewritten.
Scope it in writing
What we agree before work starts
- Claim decomposition separating settled questions from genuinely uncertain ones
- Engineering analysis and calculations for the critical constraints
Build with checkpoints
Working results, not slide decks
- Targeted experiments or benchmarks where analysis alone cannot answer
- Bottom-up cost and schedule estimate with stated assumptions and ranges
Hand over something you own
Documentation, source, and training
- Feasibility report with comparative options, risk register, and recommendation
- Draft requirements and risk register ready to carry into the next phase
Sound familiar?
Where feasibility studies earns its keep.
A manufacturer weighing a seven-figure automation investment on an unproven process step
A startup that needs an independent technical assessment before a funding round
Two competing approaches to the same problem, each with a passionate internal advocate
A grant application requiring documented engineering feasibility for the proposed work
Ask about Feasibility Studies
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
X-ray thickness gauge
Components:
- X-ray source (+ detector): Source and detector pair measuring attenuation through the material.
- Acquisition (signal chain): Signal conditioning and acquisition.
- Gauge software (thickness model): Calibrated model converting attenuation to thickness.
- Line control (feedback): The line's controller, closing the loop on thickness.
Connections:
- X-ray source to Acquisition
- Acquisition to Gauge software (calibrated)
- Gauge software to Line control (thickness)
An industrial measurement company · Industrial measurement
X-ray thickness gauge
A complete X-ray based thickness gauge: equipment assessment, hardware selection, electrical and hardware engineering, API integration, all software, and commissioning — delivered as a working instrument.
Read the case study →Common questions
Asked before every feasibility studies project.
How is a feasibility study different from a proof of concept?
A study is broader and mostly analytical: it evaluates the whole proposition — technical, cost, schedule, risk — and may include small experiments where paper cannot decide. A proof of concept is a build that attacks one technical assumption in depth. Studies often conclude by recommending a PoC on whichever question turned out to be load-bearing.
What if the study concludes the project is not feasible?
Then it earned its fee. A rigorous no at study cost, with the reasons documented, is one of the best returns in engineering — and the report usually identifies what would have to change (a component cost, a technology maturing, a relaxed requirement) for the answer to flip, so the idea can be revisited on evidence.
Will you be objective if you might build the project afterward?
That tension is real, and we handle it structurally: the study's findings are documented with the underlying analysis and data so any engineer can check the reasoning, and you own the report and are free to take it to any builder. A recommendation that cannot survive independent review is not one we want our name on.
How long does a feasibility study take?
Typically a few weeks. Purely analytical studies on a well-defined question can be shorter; studies that need supplier quotes, sample testing, or a small experiment run longer, mostly because of lead times outside anyone's control. We agree the scope and the specific questions before starting, and we would rather deliver a narrow, confident answer on schedule than a broad, hedged one late. If a question turns out to need more than the study can settle, the report says so and recommends the next step.
Can the study be used to support a grant or loan application?
Yes, and it is written with that reader in mind: assumptions stated, calculations shown, sources identified, and the recommendation separated from the evidence. We cannot promise any funder's decision, and we do not shape findings toward one. What we can do is produce a document whose reasoning a reviewer can follow and check, which is usually what a technical reviewer is looking for. Where a program has a specific format, we can structure the report to fit it.
Where this sits
Feasibility Studies, inside a r&d & prototyping system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Requirements become a bench prototype with real sensors and firmware; a test rig produces data; a pilot unit runs in the field; and the design is handed to production with everything documented.
Components:
- Requirements: What it must measure, survive and cost.
- Bench prototype (MCU + sensors): Dev board, real sensors, real signal chain.
- Firmware: Acquisition, processing, comms, update path.
- Test rig (data): Instrumented tests against known references.
- Pilot unit (in the field): A handful of units where the product will live.
- Production (handoff): Drawings, BOM, test procedure, firmware — yours.
Connections:
- Requirements to Bench prototype over handoff
- Bench prototype to Firmware
- Firmware to Test rig over serial
- Test rig to Pilot unit over handoff
- Pilot unit to Production over handoff
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.