Inpera Jan 2022 – May 2023

Making Construction Tendering Actually Digital

Increased task completion 6x and cut process time in half for construction tendering SaaS—including diagnosing a performance crisis when PM and QA were both unavailable.

My role: Product Designer (Solo)

In 2022, Inpera set out to digitize construction tendering—a notoriously complex, multi-stakeholder process that had resisted digitization for decades.

The Challenge

1

The Analog Reality

Construction suppliers were juggling email, PDF attachments, printed service specifications, and Excel spreadsheets to submit bids. A typical tendering offer took 15 minutes of constant context-switching between tools.

2

Users Didn't Want a Solution

They'd automated themselves into mastering this chaos and took pride in it. When told Inpera would "digitize their workflow," the most common response was: "We're already working digitally—we use PDFs."

3

Discouraging Initial Results

Initial pilot results showed 10% task completion rate (only managers finishing tasks, their teams giving up partway through), 20 minutes average time on task (33% slower than analog process), and users abandoning the platform mid-task to finish "the old way."

Image: Analog workflow diagram showing email → PDF → Excel → re-scan → email

My Approach

As sole designer in a product trio, I needed to prove the platform could actually improve their workflow—not just replicate it digitally.

1

Phase 1: Fix Fundamental Usability (Jan-Mar 2022)

The first barrier was embarrassingly basic: the UI wasn't responsive. Users had to scroll horizontally and vertically just to see their project overview.

  • Redesigned every component in the project view to use screen space efficiently
  • Worked with frontend developers to ensure every component was responsive
  • Got workflows on platform closer to analog familiarity, making onboarding faster
Image: Before/after of responsive design fix

Early results: Time on task: 20 min → 18 min. Task completion: 10% → 20%. Progress, but not enough.

2

Phase 2: Simplify Multi-Tool Workflows (Apr-Aug 2022)

After visiting two pilot companies for ethnographic research, I discovered the core friction: our platform forced users to replicate the tool-juggling they were trying to escape.

Key insight from site visits: Users constantly toggled between "products tool" and "offer tool." Products couldn't be linked to specific positions—only prices could.

  • Mapped the multi-stakeholder tendering chain (materials supplier → roofer → general contractor)
  • Identified which workflow steps could be consolidated
  • Proposed allowing users to add products (with pricing) directly to positions in their offer
  • Prototyped inline product addition and ran usability tests
Image: Old workflow vs. new workflow showing inline product addition
Image: User journey map or workflow diagram

Results: Time on task: 18 min → 15 min (matching analog speed for the first time!). Task completion: 20% → 45%. We'd achieved parity with analog.

3

Phase 3: The Performance Crisis (Sept-Oct 2022)

Simultaneously with my workflow simplification, the backend team refactored API endpoints to increase capacity. Their changes made my inline product addition technically possible—but had an unforeseen side effect. The entire platform ground to a halt.

Crisis metrics: Time on task: 15 min → 60 min (4x worse than before, 4x slower than analog). Task completion: 45% → 10% (back to only managers using it). Pilot teams abandoned platform entirely.

Perfect timing: The PM left (replacement not starting for 3 months), and the QA engineer went on maternity leave (cover starting in 2 weeks). For two weeks, I was the only person who could keep the product on track.

4

Phase 4: Diagnosis & Recovery (Oct 2022-May 2023)

Users kept reporting "the platform is too slow," but the backend lead insisted it was impossible—he'd just refactored for efficiency. The complaints were constant and consistent across all 5 pilot companies (~40-50 users).

The problem: We had no data to prove it. Google Analytics didn't track page load time or performance metrics.

  • Researched site analytics tools (during the 2 weeks without QA)
  • Recommended Sentry to new QA engineer on their first day
  • Got Sentry implemented within 1 week of QA starting
  • Within days, had hard data proving backend performance issues
Image: Sentry dashboard or performance metrics graph showing 10x slowdown in API response times

The data was irrefutable. The Lead Engineer audited the backend architecture, identified problematic API endpoints, and the BE team refactored with a simpler, leaner architecture (consolidating databases and reducing external dependencies).

During this 3-month PM gap, I also:

  • Co-ran ~6 two-week sprints with Lead Engineer
  • Prioritized frontend tickets while engineer prioritized backend tickets
  • Communicated directly with CEO about roadmap priorities
  • Kept product development on track despite leadership vacuum

Final results: Time on task: 60 min → 10 min (50% faster than analog process!). Task completion: 10% → 60% (managers + ~half their teams actively using it).

Image: Final high-fidelity UI showing polished, performant interface

The Solution

The solution wasn't a single design—it was persistent, multi-disciplinary problem-solving in a complex domain.

Key decisions that worked:

  • Start with fundamentals – Responsive design wasn't sexy, but it was essential
  • Research the actual workflow – Ethnographic site visits revealed tool-juggling was the real pain point, not individual tool features
  • Step outside design lane when needed – No PM? No QA? Someone had to keep product moving forward.
  • Use data to break stalemates – Backend team insisted performance was fine until Sentry proved otherwise
  • Collaborate, don't dictate – Co-running sprints with Lead Engineer, working closely with frontend developers to implement designs

The result: A tendering workflow that was genuinely better than analog—not just a digital replica of a broken process.

The Results

User Metrics

60% task completion rate (up from 10%)—managers + ~half their team members actively using platform

10 minute average time on task (down from 20 min)—33% faster than 15-min analog process

50 total users across 5 construction supplier pilot companies

Business Impact

Pilot success enabled transition from discounted pilot program to paying customers

Sales team could demo stable, performant product to close deals

Platform stable enough to build next feature (PDF parser for non-GAEB service specs)

What Happened to Inpera

Acquired by competitor Roobeo, rebranded as Conpur. My design and architecture continued in merged platform. Conpur recently acquired by Billie.de, now part of their SaaS ecosystem.

Image: Before/after metrics comparison graphic: 10% → 60% completion, 20 min → 10 min task time

Key Takeaways

1. Domain complexity requires deep research

Users didn't know what they needed because they'd never seen an alternative to email/PDF chaos. Ethnographic site visits revealed the real workflow pain points that interviews alone wouldn't have caught.

2. Versatility matters in small teams

When PM and QA were both unavailable, the product didn't stop. I researched analytics tools, co-ran sprints, prioritized tickets, and kept development moving—proving I could wear multiple hats when needed.

3. Data breaks stalemates

"The backend is fine" vs. "users say it's slow" was an unsolvable argument until Sentry provided objective metrics. Sometimes the designer's job is identifying what data you need, not just designing interfaces.

4. Beating analog is the real success metric

Getting to parity (15 min task time) felt like success, but the real win was exceeding analog (10 min). Digital transformation only works when it's genuinely better than the old way.

5. Crisis management reveals capabilities

The 3-month PM gap could have derailed the product. Instead, it proved I could handle strategic product work—feature prioritization, sprint planning, stakeholder communication—while maintaining design quality.

This project taught me that being a "sole designer" in a startup doesn't mean just making things pretty—it means being a problem-solver who can identify what's needed and find a way to deliver it, even when it falls outside traditional design scope.