Marcin Rzymek — Product Designer/ Webflow Expert at Netguru
10, 20, or more sites? No problem! - Webflow on a scale for big players
Design & No-Code
🇬🇧 English
Design & No-Code
Pickle - how to build an MVP in 2 days?
About
We will unveil the behind-the-scenes of a 2-day hackathon when as a group of 5, we created Pickle - our first product built 100% in no-code. We'll explain why we decided to go no-code and how our MVP brought us value in the very first days.
We'll share our experience of implementation in Bubble, Webflow, and Zapier, but we'll also talk about other tools that fell by the wayside. We won't skip mentioning the hidden costs of no-code.
Finally, we'll zoom in on the growing role of no-code in our industry. Most importantly, you'll learn who and what is necessary to build working products without code ;)
I will be accompanied on stage by the team we deployed Pickle with. You will meet Dawid, who used to be in love with WordPress but now carves out websites in Webflow. There will also be Wojtek, who (for the right amount of pizza) can lecture about no-code for half a day. And, of course, Ryszard, whom you'll also see in his presentation on a dedicated thematic path.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
From the recording
Talk in brief
A two-day internal hackathon case study in which a small team used no-code tools to build a working feedback product. The speakers describe selecting an idea, analyzing prepared user flows, dividing product and design responsibilities, learning around platform limits, and cutting attractive features when the data model made them too expensive. A real user validated the result immediately after the sprint. The case demonstrates that no-code is most useful as a learning constraint: time-box the experiment, make decisions quickly, and judge success by evidence rather than completeness.
Key takeaways
- 01
Create a recurring forum for product ideas
Regular internal meetings give unfinished concepts a place to find collaborators and become testable experiments.
Watch from 2:15 - 02
Begin the sprint with prepared user flows
Advance framing lets a short hackathon spend its limited time resolving decisions and building the critical journey.
Watch from 7:41 - 03
Assign explicit product and design authority
Clear roles prevent a compressed team from repeatedly reopening decisions while still allowing close collaboration.
Watch from 13:16 - 04
Cut features that threaten the learning goal
Desired avatars were removed when they required a costly database rebuild unrelated to validating the product premise.
Watch from 25:13 - 05
Evaluate the experiment through real use
A first customer completing the intended feedback behavior provided stronger validation than finishing every planned feature.
Watch from 31:24
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
Ideas need an organizational place to surface
A recurring internal forum allows people to share incomplete product thoughts before they have a formal roadmap slot. That visibility helps an idea attract the mix of design, product, and implementation skills needed for a short experiment. The meeting is valuable because it lowers the cost of asking whether a concept deserves evidence.
Watch from 2:15Preparation protects a compressed build window
The team entered the hackathon with user flows already available, then reviewed and challenged them together. This did not remove discovery; it focused the limited time on the most important uncertainties. A short sprint works better when the intended customer journey is visible at the start and can be simplified before implementation branches.
Watch from 7:41Clear hats accelerate collaborative decisions
One participant held product authority while another carried artistic and interaction responsibility. The roles did not create isolated handoffs; they clarified who would decide when time ran out. Explicit authority is especially useful in a hackathon, where consensus on every detail can consume the same hours needed to produce testable behavior.
Watch from 13:16Scope cuts should defend the hypothesis
Personal avatars were appealing, but the current database structure made them expensive. The team asked whether they were necessary to learn if the feedback product worked. Removing them protected the core journey and avoided rebuilding infrastructure for decoration. A deadline becomes useful when it forces this distinction between evidence and completeness.
Watch from 25:13A real behavior is the strongest sprint output
The team woke after the sprint to discover that someone had used the product as intended. That event mattered more than a fully polished backlog because it demonstrated the central exchange of value. The next decision could now be based on observed use, known platform constraints, and a clearer understanding of what a production version would require.
Watch from 31:24
Explore WaysConf 2026
