Kickstarting your no-code career: No Code Conf workshop day recap

This part of the no-code revolution will not be televised — or live streamed — but there's no need for FOMO. Because I was there for all the track 1 workshops, and I’m going to give you as exhaustive an overview of every session as I can.

The accidental web designer

A workshop by Jen Kramer, Lecturer at Harvard University Extension School

Who is an accidental web designer?

Anyone who didn’t intend to become a web designer or developer, but ends up doing design and development work, even if it’s not their focus.

In other words:

It’s your client, if you’re a freelancer.

It’s your collaborators, if you’re in-house.

Web design and development is going to become a necessary business skill, and the people you work with on your projects are web designers and developers too.

And it’s our job to help them do that (part of their) job better. To do that, we need to understand how people approach unfamiliar spaces like web design and development, and how we construct mental models to help guide us through the process.

The 4 stages of competence

When we set out on a project in an unfamiliar space, we go through what may become a 4-stage process that takes us from unconscious incompetence, and ends in conscious incompetence.

  1. Unconscious incompetence : How hard could it be? 
  2. Conscious incompetence : This is harder than I thought.
  3. Conscious competence : I have to concentrate, but I can do this.
  4. Unconscious competence : I could do this in my sleep.

Many of our clients and collaborators are starting at step 1: unconscious incompetence. It's our job to guide them all the way to stage 4. Or at least 3.

What is a mental model?

A mental model is what the user believes about the system at hand.

–Jacob Nielsen

Most often, users’ mental models are based in real-world experiences. Think of the wild old world of web 1.0, when most websites had what we called a “splash page.” These pages typically featured no more than a company name, logo, some supporting graphic, and maybe a tagline — plus a button to “enter” the site. That we already had “entered” the site apparently escaped us, and it was in part due to our mental model for the early web. That mental model was based on the real world: the splash page filled in for the facade and front door of a store, which we have to “enter” to see the “contents,” the products or services inside that store.

Building websites turns out to be hard for “accidental web designers” because the typical methods for building a website defy not only our mental models of what a website is, but also how building one should work.

Further, one of usability’s big dilemmas is the common gap between designers’ and users’ mental models.

–Jacob Nielsen

Because when designers start to build a site, they typically — or at least should — have a strategy in place. They know what the site should do, how its success will be measured, and they know what content and functionality it needs. (Again, all of this should be true, though it often isn’t.)

But the accidental web designer? They often don’t have any of that in place. And yet, we, the builders of no-code design tools, keep insisting that the starting point of the design process is not the story, but the scenery.

How this impacts accidental web designers

In part because of most no-code website tools’ design approach, accidental web designers' mental models for websites basically amounts to: paint by numbers. That is, a template.

Most accidental web designers see web design and development something like this: they're given a basic structure, and they just need to fill it out. Photo by Paul Sableman .

That means they have no idea of what the range of possibilities is, because the template seems to dictate what the output can be. Its shape, its form — they’re fixed. All they need to do is fill in the blanks. Right?

Unfortunately the seemingly simple task of choosing a theme or template is in fact a crippling moment for many accidental web designers. Because they don’t actually know how to fill in the blanks.

They don’t know that building a website isn’t in fact about picking a template. They don’t know that the real meat of building a site should start before picking a template, and should focus on:

  1. Writing clear, scannable copy
  2. Determining the right medium for the message you want to convey
  3. Defining the right calls to actions and the order people should encounter them in

In other words, they should start with storytelling: who’s the hero, who’s the villain, and who’s the guide . And they should always remember that those roles are fixed: 

The villain is the problem you and your business solve. And the hero? That’s your customer.

You: you’re just the guide. The one who helps the hero — your customer — solve the problem that’s blocking their success. More on this below.

The #1 resource accidental web designers need

An understanding of the process that starts with the strategy and focuses relentlessly on the user.

Don’t start with the scenery. Start with the strategy.

–Jen Kramer

Thankfully there are these things called frameworks that have been designed to help people define their strategy and story before they start thinking about the scenery. You can think of them as templates, actually — they’re just information templates, process templates, instead of visual templates.

Frameworks like the one Jesse James Garrett defined in his book The Elements of User Experience . Here’s a quick overview of that framework.


  1. What do we want to get out of the site?
  2. What do our users want? 
  3. What is the best way to serve site owner and users?
  4. How do we measure success? 


  1. What features and functionality do we need?
  2. What might we need in the future?


  1. What pages will our site include?
  2. What written content will we have, and what do we need to create?
  3. What photos and/or video will we include?


Wireframe! With annotations! Seriously folks: annotations are key tools for communicating priority, functionality, and content. Most of us non-designers don’t “speak wireframe.”


  • Balsamiq
  • Moqups
  • InVision
  • Sketch
  • Adobe XD
  • PowerPoint
  • Word
  • Google Docs
  • Pen and paper


Now that you have a picture in your head (skeleton) and the content (flesh) …

Now you can pick your theme.

The storybrand framework

Another useful framework for this is Donald Miller’s "storybrand framework," which, as the name might suggest, revolves around the timeless, essential structure of stories, focused specifically on the people who bring our stories to life.

We can understand this framework pretty easily by applying it to a “mom-and-pop” restaurant website:

  • Villain: Hunger, and bad food
  • Hero : Customer
  • Guide: The mom-and-pop restaurant

What role does your org play? You’re the guide. Your customer is the hero.

Phew , what a talk. Now let's move on to our next speaker.

I built and sold 12 no code apps in 12 weeks — here’s everything I learned

David Adkin, cofounder at Adalo

David gave us a deep dive into how to get started building no-code apps for clients, offering insights into how to find good clients, what to look for in your clients, and how to estimate, price, and sell your projects to clients.

Finding the perfect client

David evaluates potential clients’ viability as customers on a few dimensions, looking for positive signs and red flags in each dimension. See more red flags than you’re willing to deal with? Don’t take them on.

The client’s understanding of tech

Positive signs:

  • They can explain their idea
  • They have a sense for how it fits into the space

Red flags:

  • They struggle with other tech

App’s chance at success

Positive signs:

  • They have an audience
  • They have a plan for making money with it
  • It’s possible to build it with no-code tools

Red flags:

  • They don’t have a well-defined idea
  • There’s no business value in it

Client can go with the flow

Positive signs:

  • Personal connection (helps with forgiveness)
  • Fun attitude

Red flags:

  • Uncomfortable with uncertainty 
  • Tight deadline
  • They need every detail before they can commit

Commitment to their idea

Positive signs:

  • They have a team
  • They’ve taken steps to make this a real business

Red flags:

  • Change their ideas all the time
  • Too busy to commit (miss meetings)
  • No followthrough 

Finding clients

Agencies and freelancers have found years of success with 3 core methods of finding new clients, namely:

Traditional methods

  1. Social media
  2. Content marketing
  3. Social events

We dig into these and more methods in our article, " How to find freelance design work ." 

For no-code agencies, these methods still work. But the nature of our toolkit introduces a few wrinkles:

What’s different for no-code 

  • Differentiation : You’re the “new kid on the block” — the upstart with a new, different, and ultimately faster way to produce an app. That's a serious edge.
  • Existing clients : Upselling your current customers. Look back at your client roster and consider how they could benefit from a no-code app. More on this below.
  • Local advantage : Closer connection. For many companies, an app development agency might feel a bit remote, even unattainable. And that "remoteness" might even be literal. This opens a space for you to be the local team that gives them access to a technological step ahead.

Good client types

Know that you know what to look for in your clients, it's handy to know who to look at before you start that more personal evaluation.

1. Startups 

Advantage: because startups have a spectrum of design-related needs, you can be their full-service agency, delivering their branding, website, and apps. 

Find viable startup candidates through:

  • Local startup events
  • Local incubators and accelerators
  • Upwork

2. Existing businesses

Less technically inclined local businesses can still make great potential clients. Here's some tips for making local businesses into viable clients:

  • Consider what they're doing with spreadsheets now? Where do they lack automation? How can you help them make their processes more efficient.
  • Always be thinking about apps
  • Rinse and repeat: find your niche and keep going back to that well

A great example of the last point in action is Mindbody , a scheduling app for both providers and customers of fitness services.

Meeting with your clients

David then outlined the meetings you'll need to have with potential clients to both gather the information you need and make the sale.

Pre-meeting discovery

Before your first meeting, look into:

  • The client's app idea
  • Whether it's even possible to build with current no-code tools
  • Their industry

Feature discussions

  • Gather all possible features
  • Set expectations around no-code: own that you are no-code
  • Discuss native (desktop/mobile) vs. web

Initial pricing and timeline

  • Their budget
  • Explain app complexities
  • Estimate price range

Feature discussions

While discussions about website features are relatively simple, revolving around:

  • Pages
  • Blogging
  • Ecommerce

The app space is a bit more complex, with additional considerations like:

  • Multi-app/multi-use case
  • Web or mobile, push?
  • User profiles
  • Payments

While you're discussing features, keep an eye out for the following red flags, which are particularly challenging in the current no-code landscape.

Red flag features

  • AR/VR
  • Mobile games
  • Algorithmic feeds
  • AI 
  • Complex computations
  • Video tracking

Estimating time and pricing

Prioritize feature sets based on versions: Version 1 will have these features and take this amount of time, Version 2 will have these additional features and take this much time longer.

Again, be transparent and specific. Accurate timelines are key. Prioritize features that will actually get used (reviews are useless for an early-stage business with no customers … maybe).

Pricing: estimate hours and multiply by your rate. When feature creep happens, use the same formula. Most of David’s apps were $2–10K. If the rate is over 10, they probably need a more traditional dev shop. Don’t go under 2 unless you’re doing a rinse and repeat model, or you’re early stage. The more experienced and confident you are, the more you should (and can) be charging. 

Just make sure to discuss how ongoing payments, whether for continued development or mere maintenance, is going to work.

Making the sale

Here’s your secret weapon for making the sale:

Make a quick version of some portion of the app to show them their future, i.e., the app they’re going to launch. Even creating a quick MVP of a single feature in action can help them understand not just what you can deliver, but the exciting possibilities of what their company is about to deliver. 

Just don’t invest too much time in this development. Even the most powerful secret weapon can fail to sell some clients.

Once they’ve said “yes, let’s do it!” make sure you have a professional service agreement and a clearly defined scope of work. Even if it’s just an email!

Developing the app

Okay, so you’ve sold the client. Congrats! Now comes the real work. Here’s a few quick tips on that.

3 types of screens: a typology for no-code app development

That’s right: there’s really just 3 types of screens in most apps.

  1. List : Think of your social media feeds, the core of the modern social web. They’re really just lists of content produced by all the people you follow and the people they reshare. That list of products on an ecommerce site, or blog posts on a marketing site: same things.
  2. Detail : Sticking with the social media metaphor: consider your personal profile. It’s a detail page, telling people “all” about you and the content you share. Ditto for a single product page, blog post, or author page. Note though that detail pages often include lists too — lists like related posts, posts by this author, tweets by this Twitter member.
  3. Add/edit : In essence, creation and edit/update pages are the same thing. You create some content, save it, and hit publish.

Building the database

As you start creating your screens, remember that they’re just the skin over a wealth of content (or data, if you prefer). So a big part of the app development process is, in fact, designing your database.

The essence of designing your database is relatively simple:

  1. Define your nouns : they key players in your app. For Twitter, this is people and their tweets, plus subsidiary nouns that are essentially different combinations of those things, like lists, moments, and hashtags.
  2. Identify their characteristics : the things that define what those core nouns “are.” You can think of these as atoms that make up the molecules of your core nouns. For a person on Twitter, that’s your headshot, bio, header image, tweets, etc.
  3. Decide how they interrelate : the ways that different nouns reference other nouns and their characteristics. 

We dig deeper into this process and how it works with Webflow CMS in our article “ Why your design process should start with content .” 

Developing the minimum viable product (MVP)

The key thing to remember here is to work incrementally. Build up your app feature by feature, but follow every single “feature complete” stage with a thorough round of functional testing. If you don’t make sure that each feature works as soon as you build it, you’re going to end up playing whack-a-mole — fixing bugs that seem to literally create other bugs, in other features. Because at that point, your app is a complex web of interconnected elements. Moves you make in one area inevitably impact the others.

Launching the app

During the app development process, and in particular as you near completion, you’re going to want to work closely with your client on your beta , launch , and iteration plans. In other words, plan out how you want the before, during, and after of launching the app to work. 

During this process, you’re going to be switching between 3 roles:

  1. Coach : guiding your client toward the best way to run the beta, launch the app, and iterate on it based on the feature roadmap, analytics, etc.
  2. Teammate : pitching in to actually do the work right alongside their in-house team
  3. Cheerleader : rooting for your client’s team, bolstering their morale, and cheering their successes