Iterating and shipping software quickly to help you build what users want. Keeping it simple and scaling architecture over time, not right away.

1. Michael Yagudaev
Prototyping Like It’s 2022

2. About Michael
• Indie Hacker @ conceptual.so (emojination.io), Skylab and
picturethat.io
• Full-stack Developer
• Previous Life: UserTesting, Ollie Order, Consultant, PM,
Founder, UX Designer, Corporate Employee
• Web dev since 2001, professionally 2010
• O
ffl
ine: snowboarding 🏂, cycling 🚴
• 2022 Obsession: #BuildInPublic, marketing, YC Startup
School

4. Outline
• Generating Ideas
• Exploring solutions
• Dividing the work
• Iterating and getting feedback

5. Where do we find ideas 💡?
Product Market Fit

6. Audience First
• 1. Find a group of people you want to help
• 2. Find where they hangout
• 3. Talk to them to
fi
nd an interesting problem
• 4. Solve the problem
• e.g. Talking to gamers about streaming and solving
the problem of live streaming on multiple platforms

7. Problem First
• 1. Brainstorm problems you encountered
• 2. Pick an interesting recurring problem
• 3. Solve the problem
• e.g. Basecamp solved their own problem
of managing projects and clients

8. Solution First
• 1. Pick a new solution space: Web 3.0, AR/VR, AI,
new device/feature/API, etc
• 2. Brainstorm problems you can solve
• 3. Pick a problem that interests you
• 4. Find the audience (ideally you are part of it)
• 5. Build a solution
• e.g. Markus Frind created POF to experiment with
ASP.NET and pad his resume.

9. Why are you doing this?
• Learning?
• Make money?
• Get a promotion?
• Satisfy existing users?
• Satisfy new users?
• Intellectual curiosity?
• Fun?
• Good grade?
• Get a job?
• Simulated work
experience?

10. Exploring the Solutions Space
• Take a look at similar products
• Search GitHub for libraries and API that can help
• Take a look at demo projects on github or templates to get
you started

11. Example: PictureThat
• Explorered demos on Awesome ARKit
• One of them was ARBrush

12. PictureThat
• Paper Sketches

13. PictureThat
• Showed sketches to my mentor
• Challenged me to build it
• Built it in one afternoon
• July 14, 2017 - Tweet
• Launched mid-Sep, 2017 on AppStore

14. Build something people want
• 50% marketing/traction
• 50% product

15. Clickable Mock up?
• Figma / Framer
• + Useful for quickly getting everyone on the same page
• + Easier to do longer-term planning around
• - Learning curve to design tool
• - Users can’t use it to solve their problem, thus super
fi
cial
feedback
• - Easy to
fi
t too many features that can take years of
development

16. Do you want to buy this?

17. Example: Emojination
• Problem
fi
rst
• Creating interesting job ads and
announcements
• Inspired by headers.me
• Weekend project React + Next.js +
LocalStorage on Vercel

18. Why Prototype?
• Faster Feedback loop
• Get it to the hands of real users right away
• Shouldn’t take more than a few days or weeks.

19. Early Stage Startup - Ollie
• B2B Wholesale Platform for Alcohol
• V1: Spree Commerce - Jan, 2019, created a marketplace to make it easier for buyers. No one wanted that.
• V2: From scratch - March, 2019, 3 sr. devs (one played designer role)
• React, Graphql, Typescript, Apollo, Rails, Postgres, Elastic-Search, Our own Design System
• MVP: June, 2019, 3 sr. devs + 2 contractors
• Sales Litre becomes part of Ollie - October, 2019
• PHP, Angular, RESTful API
• V3: June, 2020 Rewrite
• Rails, Stimulus Re
fl
ex/Hotwire, Postgres, TailwindCSS
• 10 engineers, Jan 2021
• Sold July, 2021 NextGlass

20. Late Stage Startup -
UserTesting
• On-Demand usability testing enabling faster feedback cycles
• V1: 2007 VB
• V2: ~2010 Rewrite in Rails, Restful API, Angular.js
• V3: Graphql, Angular, Typescript, Apollo, Rails, MySQL,
Elastic-Search, Our own Design System
• Ongoing splitting into Microservices
• 200+ engineers,
fi
led IPO 2021

21. Skylab
• Started Oct 2018
• Python, Rails, React, React Native, AWS
• V1: 2018 Python ML
• V2: 2019 Rails + Python
• V3: 2020 React + Rails + Python
• Engineering: 8 Engineers, 2 Teams — ML and Product

22. What do you need?
• Fearless execution
• Relentless common sense

23. Dividing the work
• 1-person-army
• Frontend vs backend
• Full-stack by area
• Pair Full-stack on an area
• Clear the kanban board weekly
• if someone
fi
nishes their tasks, help other teammates with
theirs

24. Leadership
• Product owner and project manager roles
• Spend no more than 50% of the time on coding/design
tasks

25. Iterate, Iterate, then Iterate
again
• Your product will be 💩 day 1
• Accept it and iterate relentlessly.
• Ask people what it is 💩 for them
• One day it will be 🐛 => 🦋
• Video about design iterations: Youtube Video

26. Easier to revise
• Pick a good starting point
• Simple
• Addresses many of the requirements
• Saves you time
• Helps you focus on your unique value prop

27. Weekly Cadence
• Talk to users
• Write code
• Each week write an update and deploy code

28. Start with the UI
• Always start with the UI
• Users sees and interacts with it
• API is a UI for developers, if that’s your target user focus
on that
• Use a UI Kit or UI Starter Kit

29. UI Kits
• Find a UI kit both you and your users like
• https://chakra-ui.com/
• https://nativebase.io/
• https://divjoy.com/
• https://ant.design/
• https://mui.com/
• https://getbootstrap.com/

30. Try Pro/Templates UIs
• Plenty of great Free templates
• Consider buying pro, by pooling resources
• e.g. $20/person
• learn how authors write their code
• Hustle: email the author, tell them your poor students.
• Discount of free

31. Don’t overthink it
• Find what works for you
• Keep it simple
• Code duplication is a feature, not a bug
• Once you
fi
gure out the product based on feedback
• You can eliminate some duplication

32. Talking to Users
• Start talking to them day 0
• Figure out what they currently use and how they use it
• Let them try your product
• Capture their thoughts and feedback
• Do this every week and their feedback to guide you

33. Conceptual.so
• “AI” generated marketing images
• 4-week YC startup school build sprint
• Goal was to go beyond emojis (emojination.io)
• Talked to 21 people, 15 signups
• Focused on text => image after talking to people
• Still need more traditional graphics capabilities like Canva
and Figma offer

35. Analyzing User Interviews:
Super Human
https://review.
fi
rstround.com/how-superhuman-built-an-engine-to-
fi
nd-product-market-
fi
t
What they love What is missing

36. Possible Web Architectures Map

37. Possible Web Architectures Map

38. 1. No/Low Code

39. 1. No-Code/Low-Code Architecture
• Tools we can con
fi
gure to solve our problems
• Categories:
• 1. General Purpose hosted: Airtable, Bubble, GlideApps, Google Forms, NetSuite
• 2. General Purpose self-hosted: Wordpress, ActiveAdmin, Strapi
• 3. Website builders: SquareSpace, Web
fl
ow
• 4. Specialized hosted: ForestAdmin, Twilio Studio, Algolia
• 5. Specialized self-hosted: SugarCRM, Metabase, Odoo, SalesForce
• 6. Integration: Automate.io, Zapier, ifttt, segment.io
• 7. Web scraping: webscraper.io, ScrapeHero, ScrapeStorm

40. 1. No-Code/Low-Code Architecture
• Pros
• Fast to start
• No/little code to write
• Less expensive then writing code
• Continuously improves (receiving updates)
• Uses best practices

41. 1. No-Code/Low-Code Architecture
• Cons
• Learning curve
• Never prefect
fi
t for your use case
• Data silos in di
ff
erent tools
• Vendor lock
• No separate environments, staging/sandbox
• No automated tests
• testing tools like Ghost-inspector, solve that

42. Possible Web Architectures Map

43. 2. Static-Site

44. 2. Static-Site
• Simple HTML + CSS & JS site, no server-side logic
• Static site generators help on bigger sites: jekyll, hugo, middleman, …
• JAMStack is newer addition
• Javascript, Apis and Markup
• Gatsby.js, Netlify, Next.js*, etc
• Web apis exist for: login, shopping cart, cms, etc.
* more capable

45. 2. Static-Site
• Pros
• Simple
• Uses web standards
• Easy to build
• Maximum
fl
exibility on look & feel
• Low cost hosting
• Lightweight bundles delivered to end-user

46. 2. Static-Site
• Cons
• No direct access to dynamic data
• Data silos between 3rd-party apis
• Client-side only code, security challenges for APIs
• Requires integrating many 3rd-party services
• SEO needs to be considered (in contrast to e.g. Wordpress)

47. Possible Web Architectures Map

48. 3. Frameworkless

49. 3. Frameworkless
• Idea: minimize use of 3rd party deps
• Use language features and targeted libraries
• e.g. using raw node http server, express, sinatra,
fl
ask, next.js*
• can take approach on both client & server side

50. 3. Frameworkless
• Pros
• Shallow learning curve
• Minimal & fast system
• Less things to go wrong
• Cons
• Integration burden is upon you
• More custom code required
• Limited community support (depending on language)

51. Possible Web Architectures Map

52. 4. MVC Web Architecture

54. 4. MVC Web-Architecture
• Model-View-Controller one
fi
rst design patterns
• Divides presentation and business logic concerns
• HTML over the wire, i.e. server renders html (view layer)
• Popular frameworks: Rails, Django, Sails.js, Play Framework, ASP.net Core,
Phonix, Laravel, …
• Refreshing data requires page reloads
• Send updates via HTML Forms

55. 4. MVC Web-Architecture
• Pros
• Simple mental model
• Mature tech with good community support
• Rapid development cycle
• Fast initial load time
• Simpler for SEO
• Caching support: http caching, fragment caching, etc
• Well integrated components*

56. 4. MVC Web-Architecture
• Cons
• Certain UX pattern not possible without custom JS
• Page redirects can make for awkward UX
• Larger subsequent network requests
• Network latency will make app feel sluggish (especially on mobile)

57. Possible Web Architectures Map

58. 5. Reactive Server Architecture

60. 5. Reactive Server Architecture
• Builds upon MVC Architecture
• Adds a
fi
ner grained reactive-loop
• HTML response is di
ff
ed and changes applied
• Uses web socket connection to minimize latency
• Libraries: Stimulus Re
fl
ex, Hotwire/Turbodrive, Live View, Blazor Server,
Socketpuppet, LiveWire

61. 5. Reactive Server Architecture
• Pros
• No need for dedicated API layer
• Business logic stays on server
• Simple mental model, building upon existing one
• Cons
• Network latency
• UI state kept on server
• New and still early
• (rails) poor isolation of component state

62. Possible Web Architectures Map

63. 6. Client/Server Architecture (SPA)

64. UserTesting Direction
• V3: Scaling engineering & product
• Graphql, Angular, Apollo, Microservice/Microfrontends,
Ruby/Rails, Go, other languages
• 200+ engineers and growing
• Slowly going away from Monolith

66. 6. Client/Server Architecture (SPA)
• Client: in-charge of UI rendering
• Server: in-charge of data fetching + business rules
• Build explicit interface for communication
• REST
• Graphql
• RPC
• SOAP
• Transport medium: HTTP or Websockets

67. 6. Client/Server Architecture (SPA)
• Pros
• Decouples UI from Data
• Max
fl
exibility on client
• Simple to understand
• Cons
• Requires dedicated API
• Requires syncing state
• Duplication of logic — potential mis-match

68. Ollie in June, 2020

69. Ollie Direction
• V3: Simpli
fi
cation - June, 2020
• Tailwind, Stimulus Re
fl
ex, Rails, Database search, Our
own design system
• January, 2021 - fully replaced SPA with Reactive-Server
Architecture

70. Ollie in June, 2020

71. UserTesting in March, 2021

72. Skylab in Oct, 2021

73. Possible Web Architectures Map

74. 7. Microservices Architecture

76. 7. Microservices Architecture
• Breakdown backend monolith
• Each piece is an isolated process, either on the same or separate node
• Communication is done via Sockets, HTTP or event bus
• Protocols can be REST, gRPC, ProtocolBu
ff
, graphql
• Origin from Service Oriented Architecture (2000-2010)
• Serverless architecture is part of it

77. 7. Microservices Architecture
• Pros
• Independent deployability & scalability
• Simpler & independent code bases
• Can use many di
ff
erent languages
• Easier to assign teams with clear boundaries
• Cons
• Hard to test entire system
• Hard to change boundaries
• Tracing errors across system becomes more di
ffi
cult
• Compounding latency when services call each other
• DevOps complexity

78. Possible Web Architectures Map

79. 8. Micro Frontends

81. 8. Micro Frontends
• Breakdown frontend monolith
• Container application manages mounting/unmounting of UIs
• Pulled down at runtime

82. 8. Micro Frontends
• Pros
• Independent deployability UI + backend
• Incremental upgrades
• Simple independent code bases
• Autonomous cross-functional teams
• Cons
• Increase download size
• Inconsistency in UI between teams
• Devops complexity
• Environmental di
ff
erences between prod and dev

83. Possible Web Architectures Map

84. 9. Exotic Architectures

85. 9. Exotic Architectures
• Newer tech useful in speci
fi
c situations
• List
• CQRS/Event Sourcing
• GraphDBs - e.g. Neo4J
• Block-chain / Web3.0

86. Conclusion
Keep calm and iterate

87. One more thing…
• Participate in the community as you are
learning
• Post your wins/struggle, get inspired by
friends
• Twitter #100DaysOfCode or
#LearnInPublic
• Huge help when looking for a job
• Twitter is for Devs, Linkedin for hiring
managers

88. References
• https://martinfowler.com/articles/microservices.html
• https://martinfowler.com/articles/micro-frontends.html
• Clean Code - Robert Martin
• Clean Architecture - Robert Martin
• https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-
engineers/
• https://review.
fi
rstround.com/how-instagram-co-founder-mike-krieger-took-
its-engineering-org-from-0-to-300-people

89. Questions?
Twitter/Linkedin: @yagudaev
Website: yagudaev.com