Skip to content
← All work

Researcher Portal

I led a 0 to 1 researcher portal from kickoff to an on-time conference launch for a skeptical client, then worked with Sales to turn it into a configurable product that went to two more clients.

Gaining a client's trust on a conference deadline, then turning a one-off into a product.

3
clients on a product built for one

At a glance

Role
Product Lead and Lead Developer
Team
Me plus a senior engineer, and a Sales partner for the second act
Timeline
Q3 2025, kickoff to conference launch
Users
Rare disease researchers, with global patient advocacy groups as the clients: one at launch, then two more
Metrics
Shipped on time, 3 clients, part of $800K in new contracts and $75K upsell ARR

Problem and stakes

Lumiio's flagship product was built for patients. A client, a global patient advocacy group, needed their researchers to access and work with that data directly, which the product had never done. Their previous vendor could talk the talk but could not walk the walk, so they arrived skeptical and with little patience for surprises.

The launch date was fixed to an international conference where the client would present the portal on stage. Missing it would have cost the contract and the relationship. It mattered to Lumiio too: this was our first researcher-facing product, and a test of whether we could serve that segment at all.

I owned requirements, client communication, scope decisions, the build and launch readiness. Partway through, it became clear the original scope would not fit the deadline. The client was asking for a full research workbench. What they needed on stage was a working portal that a researcher could log into, find a cohort, and show real data moving.

From kickoff to three clients
  1. Kickoff
    Requirements, client communication and the build, with a senior engineer
  2. Scope cut
    Launch list and deferred list agreed in writing
  3. Conference launch
    Shipped on time, presented on stage
  4. Repackaged with Sales
    Configuration replaces custom code, and the portal goes to two more clients
  • Scope cut
  • Launch
  • New client

What I did

  1. 01

    Cut to what the conference demo needed, and wrote down what "done" meant

    I separated what the client had asked for from what the presenter needed on stage, then put the shipped list and the deferred list in writing and got the client to sign off on both before the cut.

    Tradeoff. The client gave up the custom report builder for launch. In return, nothing on the launch list was allowed to slip, and the deferred list had dates attached.

  2. 02

    Deferred study collaboration and sharing to a post-conference release

    Sharing needed a permissions model for people outside the client's own team, which meant a data model change that would have put the launch at risk, and nobody would see it in a 20 minute presentation.

    Tradeoff. It cost us a feature the client cared about. I explained the reasoning to the client and to leadership before the conference, not after, so nobody was surprised.

  3. 03

    Kept data correctness and access control non-negotiable

    A researcher portal that showed the wrong patient's data on stage would have ended the relationship. I protected the time for permissions, audit and data checks even when other things were being cut.

    Tradeoff. Less polish in the UI at launch. The client agreed that correct and plain beat pretty and wrong.

  4. 04

    Gained a new client's trust by delivering everything we talked about

    The client's previous vendor could talk the talk but could not walk the walk. It mattered to me that everything we discussed was something I could act on and deliver, so I ran a demo every week, sent honest written status updates, raised risks early with options attached, and kept the written scope agreement current.

    Tradeoff. The cadence cost me build time every week. It was worth it: by launch the client was forwarding my updates to their own leadership.

The second act: from one client to three

After launch I worked with Sales and Product to redefine the portal as a platform rather than a one-client build. That meant replacing custom code with configuration, deciding which features became standard, and agreeing how to package and price it. It went to two more clients.

Custom code
Per-client configuration for data fields, cohort definitions, export formats and branding
One-off features
A standard feature set every client gets, with the custom report builder as a paid add-on
Bespoke pricing
A packaged offer Sales could quote without engineering in the room: a platform fee, a per-study fee, and the add-on priced separately
Asked for
  • Researcher login with role-based access
  • Cohort views of patient-reported data
  • Export of study data
  • Custom report builder
  • Study collaboration and sharing
Shipped for the conference
  • Researcher login with role-based access
  • Cohort views of patient-reported data
  • Export of study data
Came later
  • Custom report builder
  • Study collaboration and sharing
  • Per-client configuration (the platform work)

What went wrong

I locked the scope agreement later than I should have. For the first five weeks the client and I were working from a shared understanding rather than a written one, and when the deadline pressure arrived, the cut was harder to explain than it needed to be. I also built the first version for one client rather than for reuse, which meant the second act cost more engineering than it would have if I had designed for configuration from day one. Both are things I now do at kickoff.

Results

  • Shipped on time for the conference, and the client presented it on stage using the live portal rather than slides.
  • Went from one client to three after the portal was repackaged as a platform.
  • Part of the $800K in new contracts, and the source of the $75K in upsell ARR from the add-on and configuration sold to clients two and three.
  • Fourteen researchers onboarded across the three clients, supporting five studies.

What I'd do next

  • Write the scope agreement and the definition of done in the first week, before the first line of code.
  • Start every 0 to 1 build with the question of who the second customer is, so configuration is designed in rather than retrofitted.

Why this matters

Growth and self-serve roles are about turning one good experience into a repeatable one. The second act here, one client to three and custom to configurable, is that work. It also shows the Sales and CX partnership most PM roles ask for: I repackaged the portal with Sales and built the enablement that let CS support it.

Next case study

Questionnaire builder refactor

I made the case for and led a refactor of the questionnaire builder, the tool every study on the platform depends on, after bug tickets, admin interviews and a slow, clunky experience all pointed at it. Builder support tickets fell 100% in the six months after launch.

  • Refactor
  • Discovery
  • Admin tooling
  • Support partnership
Read the case study →
100%
drop in builder support tickets, six months after launch