A feasibility study the client turned into a launched product, and a company.

The situation

The client had a product thesis: document signing where the integrity and provenance of the signature could be cryptographically verified, not just asserted by a platform you have to trust. Before betting the company on it, they needed to know two things. Does the technology actually support the promise? And what architecture would carry it from concept to product?

The constraints

• The answer had to be honest. A feasibility study that flatters the idea is worse than useless. It burns the runway the client would need to change course.
• Legal-context signing carries evidentiary requirements; "cryptographically neat" isn't enough if the output can't stand up where it matters.
• The client was going to build this with their own team afterwards. The architecture had to be one they could own, not one that needed me indefinitely.

What I did

Technical design and feasibility, treated as an engineering exercise rather than a research exercise: which signing and verification approach fits the use case, where blockchain genuinely earns its place in the stack vs where a conventional component does the job better, and what the build actually looks like: components, integration points, and the risks worth watching.

The output was a validated approach and an architecture the client's team could take straight into the build.

The outcome

• The approach was validated, with the trade-offs stated plainly, not buried.
• The architecture directly informed the build that followed.
• The client went on to launch a successful product and build a company around it.

Why it worked

This is what a good feasibility engagement is for: not to produce a document, but to let someone commit with confidence. The client didn't need me on the payroll for the years that followed, they needed the right answer and the right starting architecture at the moment the decision was made. That's capability transferred, not dependency created.

This maps to the Technical & product support engagement on the services page, with early-stage scoping often starting as a short rapid exploration.