~/work/paranano/

ParaNano

Built a Next.js product platform that explained WoundCue, ParaNano’s wound-care nanofiber concept, for investor demos, company updates, and customer conversations.

The ParaNano logo mark and wordmark on white, above a yellow-to-green gradient
Role
A Unified Whole · Software Engineer
Period
Mar 2025 – Aug 2025
System
wound-care product platform
wound careproduct communicationnextjsresponsive webNext.jsReactTailwind CSScontent architecture

The product was scientific before it was digital

ParaNano needed a web surface that could explain a wound-care concept without turning it into either marketing fog or a research paper.

Jeff Visoky created the brand and web design for ParaNano. He gave me the visual direction and page designs; I implemented the site and its content system in Next.js and Tailwind.

WoundCue is publicly described as a battery- and wire-free nanofiber membrane designed to integrate into wound dressings and passively change color when bacterial or fungal activity reaches a critical level. The software problem was not building the device. It was helping investors, partners, and prospective customers understand what the concept was intended to do, why early indication matters, and how it could fit into a wound-care workflow.

That required careful language. The site could explain the mechanism and the company’s public direction, but it should not imply clinical validation or regulatory status that the available evidence did not establish. I treated content hierarchy as part of the implementation: distinguish the problem from the proposed mechanism, separate technical context from calls to action, and let public research or company updates carry claims that belonged to them.

The result needed to feel credible to technical and nontechnical readers at the same time. That tension shaped the page structure more than any visual trend.

A fast prototype still needed a system

The first investor-facing version came together quickly, but it could not remain a pile of presentation pages.

I built the platform in Next.js and Tailwind, using reusable layout, typography, media, article, and contact primitives so the early prototype could become a coherent site. The system had to support product explanation, company context, news, research-oriented content, and ways for prospective customers to get in touch without making every new page a custom build.

Component boundaries made revision easier as the company’s story evolved. A change to the navigation, typography, content width, or responsive media treatment could apply across the product and news surfaces. Content blocks could move without losing spacing or hierarchy. That mattered in an early-stage company where the words and priorities were still changing alongside the software.

The implementation stayed intentionally straightforward. The purpose was to make the product legible and maintainable, not to introduce infrastructure that the site did not need.

The information architecture carried the technical story

A useful page had to answer questions in the order a reader would actually ask them.

The top-level flow moved from the wound-care problem to how the membrane was designed to respond, then to the audience and next action. Supporting pages could go deeper into the pathogens and research context without forcing every visitor through the same density. News and company updates added evidence of activity without being confused with medical proof.

I used restrained visual hierarchy and responsive layouts to keep long scientific terms, diagrams, and supporting copy readable. Calls to action remained visible, but they did not compete with every paragraph. The goal was a product presentation that felt clear enough for a demo while still respecting the complexity of the underlying science.

That work reinforced a lesson I had learned in other domains: clarity is not the same as simplification. A page can remove unnecessary friction without removing the distinctions that make the subject accurate.

Public facts set the boundary

The company’s live site and published updates became the authority for outward-facing claims.

Public material describes WoundCue as a nanofiber membrane intended to indicate pathogenic activity through a color change, and company updates discuss research and manufacturing progress. I used that material to ground product terminology and avoided extending it into claims about diagnosis, clinical outcomes, or approval.

The same principle applied to project impact. The platform supported investor demonstrations and customer conversations, but the case study should not attribute funding, partnerships, or scientific progress to the website. Software can help a company present and operate its work; it does not become the cause of every business milestone that follows.

Keeping that boundary explicit made the writing stronger. It let the engineering story focus on what I actually built: a fast, responsive, maintainable product platform for explaining a specialized medical-device concept.

What I took from the project

ParaNano taught me how much technical judgment can live inside a small public website.

The codebase was not the largest system I have built, but the consequences of loose language were higher than on an ordinary landing page. Component design, content modeling, source verification, and visual hierarchy all affected whether the product was represented honestly.

I left the project with a better way to approach unfamiliar domains: learn enough of the domain to preserve its important distinctions, identify which claims have an authoritative source, and build the simplest system that lets the story evolve without rewriting the whole site.

  • Separate the problem, proposed mechanism, and evidence instead of blending them into one marketing claim.
  • Use reusable content and layout primitives even when the first prototype must move quickly.
  • Treat live first-party material as the boundary for medical and business claims.
  • Measure the software by clarity and maintainability, not by milestones it did not cause.