
No-Code Developer - meaning who?
About
What was a novelty a few years ago today surprises no one. Websites and products run on no-code technology, and their creators dub themselves No-Code Developers.
So who is a No-Code Developer? A designer who digs Webflow? Or a developer who speeds up his or her work?
In my presentation, I will talk about the career path of a No-Code Developer and how I lead a team at Tonik that specializes in no-code solutions.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
Talk in brief
A history of adopting Webflow and no-code development inside an agency, from early experiments and freelance demand to team integration and production delivery. The speakers describe a learning path that included copied code snippets, increasingly complex implementations, close developer review, and a gradual improvement in generated code quality. No-code proved useful for discovery and tangible prototypes, but its production role depended on scale, maintenance, integrations, and team competence. The case argues for a hybrid practice rather than a tool-based identity.
Key takeaways
- 01
Adopt tools when their ecosystem becomes viable
Webflow’s usefulness grew with the platform and surrounding practice, making timing part of a responsible technology choice.
Watch from 2:18 - 02
Use real demand to grow capability
Incoming freelance and agency projects created concrete problems around which the team could recruit and learn.
Watch from 7:50 - 03
Learn no-code through an actual product
Building a team product showed that visual development could support more than decorative websites and marketing work.
Watch from 13:34 - 04
Read the code even when tools generate it
Inspecting snippets and collaborating with developers helps visual builders understand failure, constraints, and maintainability.
Watch from 25:03 - 05
Choose no-code according to lifecycle needs
Discovery and tangible prototypes are clear strengths, while production suitability depends on integrations, scale, and ownership.
Watch from 37:23
Video chapters
- 2:18The beginning of the Webflow era
The talk places adoption within the platform’s early development and a wider history of visual web tools.
- 7:50Demand grows beyond one freelancer
A flood of projects forces the practice to recruit help and turn individual knowledge into team capacity.
- 13:34A no-code product built by the team
An internal experiment expands visual development from presentation sites into product behavior.
- 19:23When copied snippets do not work
Custom code introduces debugging and exposes the limits of using fragments without understanding them.
- 25:03Learning from each larger implementation
Progressive projects and developer collaboration build technical literacy around generated code.
- 31:23Developers reassess improving output quality
Cleaner platform output changes perceptions shaped by earlier, less maintainable visual builders.
- 37:23Discovery value and production tradeoffs
The Q&A compares tangible prototypes with the long-term requirements of implementation and maintenance.
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
Technology readiness changes the adoption decision
A visual builder may be interesting before it is dependable enough for professional delivery. Platform maturity, output quality, community knowledge, and integration options all affect the right moment to adopt. Teams should revisit earlier judgments as the ecosystem changes, while testing against real requirements rather than the excitement of a new interface.
Watch from 2:18Real projects turn curiosity into capability
Incoming demand gave the practice repeated, concrete problems to solve and eventually exceeded what one person could deliver. Recruiting and collaboration became necessary. This pressure helped no-code knowledge become an organizational capability, but it also required conventions, quality checks, and a clearer account of which projects the approach could support.
Watch from 7:50A product experiment expands the mental model
Building an actual no-code product forced the team to address logic, state, data, and collaboration rather than only page composition. The experiment demonstrated possibilities and exposed limits in a setting where learning was the main goal. That evidence was more useful than debating whether no-code was categorically suitable for product work.
Watch from 13:34Generated systems still require technical literacy
Visual tools can hide implementation details until a copied snippet fails or an integration behaves unexpectedly. Reading the resulting code, learning from larger projects, and reviewing work with developers builds the ability to diagnose risk. The goal is not to recreate every feature manually, but to understand enough of the system to own its consequences.
Watch from 25:03Tool choice depends on the product lifecycle
No-code can make discovery prototypes more tangible than static design files and can support some production products effectively. The decision changes with traffic, data, integrations, accessibility, performance, maintainers, and expected lifespan. A hybrid team selects the approach per product stage and constraint instead of defending one implementation identity.
Watch from 37:23

