Est. reading time: 6 min read

2025: The Year Lensym started to become reality

company updateproduct visionretrospectiveyear in reviewfeatured

A look back at a year of building a survey platform from scratch. What we shipped, what took longer than expected, and what we learned along the way.

2025: The Year Lensym started to become reality

This is the kind of post we almost didn't write. It's easier to talk about features than process. But if we're asking people to trust us with their research, we should probably show who we are.

2025 was the year Lensym began to be built.

Not "launched" (we're still in early access). Not "scaled" (we're a small team). Built. From the first commit to something people are actually using to collect real data.

Here's what that looked like.

Why We Started

The honest version: frustration.

We'd spent years using survey tools that either did what we needed but felt like enterprise software from 2008, or looked modern but couldn't handle conditional logic beyond "if yes, skip to question 5."

The breaking point wasn't dramatic. It was cumulative. Another afternoon spent debugging branching logic we couldn't visualize. Another "collaboration" workflow that meant exporting, emailing, merging, and hoping nothing broke. Another GDPR compliance checkbox that clearly meant "we'll figure it out later."

We kept saying "someone should build something better." Eventually we realized we were the someone.

What We Actually Built

By the end of 2025, Lensym has:

A graph-based survey editor. This took the longest and was worth it. Surveys aren't linear, so why are we forced to build them in a list? The graph editor lets you see branching, spot dead ends, and understand flow at a glance. Once you design surveys this way, going back feels impossible.

Real-time collaboration. Multiple people editing simultaneously, changes syncing instantly, no "someone else is editing this" lockouts. We use conflict-free replication similar to what powers real-time editors like Google Docs. It works. Teams can actually design surveys together instead of passing files back and forth.

Expression-level piping. Not just "insert previous answer here" but actual calculations. {{salary / 12}} for validation. {{if(score > 70, "qualified", "screened_out")}} for routing. When researchers say "I need the survey to calculate this," we wanted the answer to be "yes" instead of "you'll need a workaround."

17 question types with proper validation, accessibility, and mobile support. Not 50 (half of which nobody uses), not 5 (forcing workarounds). The ones researchers actually need, built properly, and we are actively analyzing what needs to be added.

GDPR compliance that isn't bolted on. EU data residency. No third-party tracking cookies. Pseudonymization options. Retention policies. This isn't a feature list, it's how the system was designed from day one.

Analytics that answer the right questions. Completion rates, drop-off analysis, cross-tabs, response distributions. Not everything (we're not trying to replace R or SPSS), but enough to know if your survey is working before exporting for deeper analysis.

What Took Longer Than Expected

Everything, in the most literal way possible. But specifically:

The graph editor. Making surveys feel like flowcharts sounds simple until you try to handle every edge case: circular dependencies, conditional visibility, branching that branches again, undo/redo across collaborative sessions. The core logic has been rewritten more times than we could keep track of.

Piping expressions. Supporting {{variableName}} is easy. Supporting {{if(a > b, option1, option2)}} with proper type checking, error messages, and preview is less easy. We built a parser, threw it away, built another one.

Mobile responsiveness for complex question types. Matrix questions on a phone. Ranking questions with drag-and-drop on touch screens. We underestimated this by months.

What We Learned

Researchers are underserved. We knew this intellectually. Talking to early access users made it visceral. The workarounds people build to make existing tools do basic things, the hours spent on tasks that should take minutes. The bar is low because nobody's been trying to raise it.

"Simple" and "powerful" aren't opposites. We spent a lot of time on progressive disclosure: keeping the interface clean for simple surveys while making advanced features accessible when needed. This is harder than picking one or the other, but it's the right approach. Not everyone needs expression piping. Everyone deserves to not be overwhelmed.

Build the thing, then write about it. We started the blog mid-year with practical guides on survey methodology. Writing about branching logic, bias reduction, validity and reliability, it sharpened our thinking about what the tool should do. The content isn't marketing. It's how we work through problems.

Early access is humbling. Real users find issues you never imagined. They use features in ways you didn't intend. They ask "can it do X?" and you realize X is obvious and you forgot to build it. Every bug report is a gift (even when it doesn't feel like one).

The Numbers (Honest Version)

We're not sharing vanity metrics. Here's what actually matters:

  • Surveys created in early access: Enough to find real bugs and confirm use patterns
  • Response data collected: Enough to trust the infrastructure
  • Features shipped: More than we planned, differently than we planned
  • Rewrites: More than we'd like to admit
  • Times we questioned everything: Several

We're building something we believe in. We're not pretending to be bigger than we are.

What's Next

2026 is about getting Lensym ready for broader use.

Not "launch" in the sense of a press release and a countdown timer. More like: removing the rough edges, filling the gaps, making sure that when someone trusts us with their research, it's because we earned their trust.

Specifically:

  • Survey templates and starting points
  • Further refinements to progressive disclosure
  • Integrations with the analysis tools researchers already rely on
  • More export options
  • Even better performance
  • Complete documentation
  • Features we've heard requested repeatedly in early access

We'll share more as it happens. For now, we're heads down building.

Thank You

To everyone who requested early access, reported bugs, asked hard questions, and trusted Lensym with real research: thank you.

Building in public means people see the rough edges, which can be intimidating. You saw them and gave us feedback anyway. That's how good software gets built.


If you've been waiting to try Lensym, early access is open. We're not ready for everyone yet, but we're ready for people who want to shape what this becomes.

→ Request Early Access


Here's to 2026.

The Lensym Team