Proof Library
Owned the proof store behind a sales-AI product: ingestion, a user-facing dashboard with search, and a tagging layer that kept every customer's library organised on its own.
Problem
GrowthNation was a stealth startup still looking for product-market fit, and it looked by pivoting. It started in AI content marketing. About three months before my contract ended, the CEO moved the whole product to a "social proof OS for sales teams." (After I left it pivoted again, towards AI-driven org optimisation: interviewing employees with AI to surface improvements people used to find by hand.) Shipping real product across those swings was the actual job.
The sales pivot needed one place to hold a company's proof: case studies, customers, testimonials, stats. Other parts of the product would read from it to assemble tailored pitches. It didn't exist yet, and the two surfaces that would consume it, proof delivery and proof collection, were being built at the same time by other engineers. Someone had to own the store in the middle and make it real. That was me.
Constraints
The scope came from the founder, who judged the work on business impact rather than implementation detail. Every major delivery went out with a written summary he could read in a couple of minutes. The skill there was being a reliable human in the loop, not producing more words.
The team was small and shipped fast on heavy AI assistance, which also meant tech debt stacking up quickly. What I was paid for was direction, judgement, and knowing when the AI output was wrong.
An empty proof store is useless, so onboarding a new customer had to produce a usable, organised library straight away.
Approach
I split the store into three layers and built each one with AI assistance under my own review.
Ingestion came first. The public-scrape lane runs end to end: paste a URL, it extracts, and appears in the dashboard. On top of that, uploads of any kind (docs, PDFs, plain text) plus screenshots run through AI vision to pull quotes and testimonials straight out of images.
Presentation was a user-facing dashboard that had to work for every workspace on real data, and the CEO wanted it front and centre. It ran as two tabs. The Dashboard tab gave the overview: coverage percentage, total items, gaps, and last contribution across the top, then a coverage matrix broken down by ICP with a bar per pain point, rows you can expand to the underlying quotes and stats with their source, a consented-only filter, and a sidebar of live contributions. The Explore tab was for digging into the store itself, so a user could find a specific piece of proof by filtering, sorting, and fuzzy-searching across the whole database.
The tagging layer was the decision that mattered most. Every new quote, stat, or case study gets tagged against the workspace's ICPs and pain points before the save call even returns, and when a workspace edits its ICPs or pain points, everything already stored gets re-tagged. That is what let a brand-new customer have a useful library on day one, and what kept it accurate as their positioning shifted.
Alongside the store I took over an autonomous bug-triage system the CTO had started. It does root-cause analysis (ordering events in time, trusting server logs over client, fingerprinting errors, catching cascades) and opens its own fix PRs, so a triage points at the cause instead of whichever symptom surfaced first.
Contribution
I owned the store, its ingestion, and its presentation, and exposed all of it over a custom MCP layer so agents could read it too. I wrote the delivery summaries that went out with each milestone, including what got left out on purpose: the first dashboard shipped behind a feature flag for every workspace, with the deferred items named openly rather than dropped without a word.
Outcome
The store, dashboard, and tagging layer shipped and ran for every workspace on the platform. The product was demoed at a conference in June 2026, and the company had earlier reached the top 10% of a YC application round.
Reflection
The lasting lesson here was about altitude, not code. The technical side was hard in its own right: the dashboard was a blank-page design problem, and getting to a working prototype inside a week leaned on skilful use of AI. What I grew most, though, was operating at the founder's level, reporting in business outcomes he could act on rather than implementation detail he didn't need.
“Arkadiusz is a strong self-starter who is diligent and righteous when it comes to building product, but measured and pragmatic about delivery so doesn't allow himself to get pulled into over-engineering. He is an excellent team-member capable of learning quickly and mentoring those around him. His focus and selfless drive mean I would happily recommend or work with him again.”