Co-founder & Design Lead · 2025 · Reyda
Designing clarity into complex procurement operations
Reducing cognitive load in document-heavy procurement processes through unified discovery, AI-powered comprehension, and guided qualification
Reducing cognitive load in document-heavy procurement processes through unified discovery, AI-powered comprehension, and guided qualification
8× more tenders pursued in the same working hours
Measured in a single-company pilot and held across five more. Qualification stopped being a bottleneck, and time shifted from interpretation to decision-making. This produced a fundamentally different process rather than a faster version of the old one.
Earlier go/no-go decisions
Teams are able to assess viability within hours instead of days, reducing time spent on low-fit opportunities and moving from reactive response to intentional selection.
Funded by investors
I presented the thesis directly to investors, walking them through the problem framing, the pilot data, and the product direction. The product secured early funding, validating both the problem space and the commercial potential of the approach.
EU public procurement is a €2 trillion market, roughly 14% of GDP, and open to any qualifying company across all member states. Tenders are standardised and consistently published. On paper, access is not the problem, but participation tells a different story.
Single-bidder tenders increased from 23.5% in 2011 to 41.8% by 2021. Cross-border participation remains below 5%. SMEs win most contracts by count, but far less by value. Companies either drop out early or do not complete the process.
The workflow has been digitised without being simplified. Teams still read through long documents, extract requirements manually, and rebuild structure before they can make a decision. That work happens before anything meaningful starts, and between a published tender and a go or no-go decision, there is a large amount of manual interpretation that repeats across every opportunity.
Two views into the work that informed the product. The existing workflow — how it actually plays out for the teams who run it. Then a competitive analysis — what already exists in the market.
To understand where to differentiate, I looked across tools used in procurement workflows.
Most legacy products supported parts of the process, but the gaps were consistent.
Discovery was handled by portals and alert systems. Response was supported by workflow tools and proposal generators. The breakdown sat in between, as understanding and qualification remained manual.
My co-founder and I started with a simple assumption: improving how teams discover and track tenders would increase participation. I worked closely with a mid-sized EU procurement team, sitting in live bid meetings and shadowing active tenders, and focused on the parts of the workflow that do not appear in process documents, the re-reads, the backtracking, the points where teams quietly stop.
To test whether this held beyond one team, I spoke to 24 procurement professionals across six EU countries, across both public and private sectors. The same patterns showed up.
The main friction shows up at qualification, where teams have to interpret requirements and map them to internal capabilities. Most of the time is spent building enough clarity to decide whether to proceed.
Across teams, the goal was consistent: move from discovery to submission faster than competitors, and progress depended on how quickly a team could piece together what mattered.
Looking across countries, the workflow itself stayed largely the same, but the differences sat in the surrounding infrastructure: multiple portals, inconsistent formats, and fragmented submission systems. The effort required to reach clarity remained constant.
The pressures were consistent across teams. Titles varied, responsibilities overlapped, and in many cases one person operated across multiple roles depending on the stage of the tender. What changed was not the goal, but where each role felt the friction most.
As a procurement manager, I need to determine whether a tender is worth pursuing, so that I can avoid spending time on opportunities we will not win.
As a bid manager, I need to understand key requirements without reading everything, so that I can assess viability within hours instead of days.
As a project lead, I need to identify what is missing early, so that I can avoid late-stage blockers and rework.
As a bid team member, I need to move from evaluation to response without starting from scratch, so that we can act quickly when an opportunity is a strong fit.
The competitive analysis showed where the market wasn't looking. The existing workflow showed where teams were quietly losing time. We took both, redrafted what the future could look like, and landed on three Solves — the spine everything else would sit inside.
Everything that ships sits inside one of these three. The experience section below is where each one comes to life.
Qualification consumed the majority of effort before proposal work could even begin. Teams spent days monitoring procurement portals, reviewing opportunities, coordinating internal expertise, and manually assessing eligibility before determining whether a tender was worth pursuing.
The future state required teams to answer one question as quickly as possible:
“Is this worth pursuing?”
The challenge was not helping users find more tenders. The challenge was helping them reach a confident go/no-go decision faster.
Rather than designing around documents, we designed around decisions. Every interaction was evaluated against a single principle: reduce the effort required to qualify an opportunity.
This led to four design moves:
In the baseline pilot, the existing qualification workflow took 2 to 6+ weeks end to end, with go/no-go decisions arriving days after a tender first landed. With the fit score in place, the same team reached those decisions within hours.
The shift was less about speed for its own sake and more about where the time went. Qualification moved from days of manual interpretation to hours of structured decision-making, so teams stopped reading hundreds of pages to find out a tender was a poor fit and started ruling it out in the first sitting.
Even after identifying a promising opportunity, teams still faced the most time-consuming part of the workflow.
Requirements, obligations, risks, and evaluation criteria were buried inside lengthy procurement documents. The bottleneck was no longer access to information. It was interpretation.
The goal was never to summarise documents. The goal was to reduce interpretation effort without reducing trust.
Early concepts focused heavily on AI-generated outputs, but research consistently highlighted the need for transparency and verification. The challenge became:
How might we help teams understand complex procurement documents faster while maintaining confidence in the underlying source material?
Reading shifted from a multi-day slog to a conversation with the document. Where bid managers once reviewed hundreds of pages over 5 to 10+ days and spent another 3 to 7 days extracting requirements, they now interrogated the source directly, pulling out obligations, scope, and red flags without working line by line.
The qualitative shift mattered more than any single number. Teams stopped describing the work as reading and started describing it as questioning the document. One bid manager's user story captured the new posture cleanly: the need to “understand key requirements without reading everything, so that I can assess viability within hours instead of days.” That sentence, written before the product existed, became a literal description of how the work felt in pilot.
Confidence held because the answers stayed anchored to the source material. Across the pilot, the question “Is this worth pursuing?” stopped requiring a full read to answer.
Understanding a tender is only valuable if teams can act on it.
Research showed that qualification work frequently broke down once teams moved into compliance, forms, proposal writing, and submission. Knowledge was repeatedly recreated at every stage.
The objective was not simply automation. The objective was continuity.
Information generated during qualification should flow naturally into every downstream activity. Rather than treating submission as a separate workflow, qualification and submission became part of a single connected experience.
In pilot, the same team working the same hours moved through 8× more tenders, because qualification stopped being a multi-day re-reading exercise and became a structured decision made in hours.
The pattern held when the rollout extended to five more organisations of different sizes, sectors, and tender volumes. Teams reached go/no-go decisions within hours, qualification uncertainty dropped, and drop-off on viable tenders fell sharply.
The shift was not speed alone. It was a reusable organisational memory carried forward between tenders, so teams stopped rebuilding context from scratch and started compounding what they already knew.
Rather than ship broadly, I designed the rollout as a structured pilot. One company first, then five more, then a case for investors, then a direction the pilot itself surfaced.
Before introducing the product, I shadowed a mid-sized procurement team over several weeks and tracked how long each workflow stage actually took. That gave us the 2 to 6+ week current-state number. I then moved the same team onto the product and held their working hours roughly constant. In the same window, they worked through 8× more tenders, because qualification shifted from days of manual interpretation to hours of structured decision-making.
Once the first pilot stabilised, I extended the rollout to five more teams of different sizes, sectors, and tender volumes. The pattern held: go/no-go decisions consistently within hours, qualification uncertainty dropped, and drop-off on viable tenders fell sharply.
Once the pilot data was stable, I compiled the findings — workflow timings, the 8× outcome, behavioural patterns — into a case for investment. I presented this directly to prospective investors, walking them through the problem space, the EU market context, and the product direction. The product secured early funding shortly after.
A pattern emerged across the smaller organisations in the expanded rollout. Many were qualified in part but not fully, close to winning on their own merits and reliably excluded by requirements around team size, financial thresholds, or combined capability coverage. This pointed to a direction we hadn't originally scoped: consortium bidding, a mechanism for smaller companies to pool their qualifications, share documentation responsibilities, and compete together for tenders none of them could pursue alone. This is in active design rather than yet built; the pilot made the case for it more clearly than any amount of upfront research could have.
What I take most from this is how I now think about AI. The product worked because AI sat at the foundation, doing the heavy data work of reading, interpreting, and structuring that the workflow used to absorb on its own. Every other decision we made was built on top of that one, which made the rest of the system compose more cleanly. AI was the premise the whole product was built around.
And the only honest measure of whether the work succeeded is whether the people using it reached their goals faster and with more confidence. Output on its own says very little. The product earns its place when users move from hesitation to action.