Hello community builders! It’s been a minute month? 😅
I started this newsletter with the lofty ambition of a new issue each week, but between my work at Glide and family obligations, the newsletter moved to the backburner.
But I’m not giving up! Last week I joined Tightknit to talk about low-code tools for community builders.
.png)
I figured that session could get this newsletter back on track. So here we are.
Low-code tools have been around for a while.
Rewind to the 90’s with tools like Visual Basic, HyperCard, Microsoft Access, and Dreamweaver.
They were all intended to make software development more approachable, so even if you weren’t comfortable with code, you’re still able to build.
30+ years later and we’re still employing the same visual development methods. With those same methods come the same challenges:
Steep learning curve of different tools
Restrictions for what those tools let you do
Tool lock-in with no ability to migrate elsewhere
Enter AI and vibe coding. You don’t need to learn a programming language or a visual development tool. Just prompt what you want into existence and let AI figure out the details. And because it’s code, you have freedom to host it wherever you’d like.
It’s a new frontier, and it’s exciting!
But code is only part of the work that goes into building software.
It all starts with a plan.
The approach I’ve used for every project over the last 15+ years:
Defining your requirements
Designing your solution
Developing & deploying
Documenting what you’ve built
Distributing it to users, in phases
It’s fundamental and platform agnostic. Digging into each step…
1. Defining your requirements
Who are your users?
Who are you building for? Is it for you? Is it for your team? Is it for your members? Different types of users will need different experiences and capabilities.
What do they need to do?
What are the essential features and functionality? What’s critical versus just a nice-to-have? You’ll start with the essentials and expand from there.
What does success look like?
How will you know if it’s working? You need success criteria for that, but you also need it for justifying the up-front time you invest.
Shape your requirements as user stories.
If you’re building a tool for yourself, fantastic, that’s a great place to start. You know what you need and you can move quickly. But if you’re building for others, you need to talk to them to understand what they want and why it’s important.
It’s a simple formula: as a [blank], I want to [blank], so that I can [blank].
For example: As a community manager, I want to log internal notes about specific community members, so that I can share the notes with my community team.
2. Designing your solution
What kind of data will you work with?
If you’re working with existing data, where will it come from? If you’re starting from scratch, what new data will you need to capture?
I find spreadsheets helpful for planning because they’re familiar and flexible.
So let’s say we’re working with member profiles for a customer community. Our spreadsheet data may include the member’s name, company, bio, contact details, and information about what products they use.
We have a column for every unique piece of information. To connect it all, we have some unique identifier for each row, like a Member ID that never changes:
Example spreadsheet dataset of member profiles
How will you present the data?
We want to show the right data to the right people in the right way.
That’s what interfaces are all about.
Going back to our member profiles example, let’s say we want a visual directory with search capabilities to quickly find member profiles and pull up their notes or details.
We can visualize the essentials by wireframing. Tools like Miro and FigJam are solid options, but jamming on a whiteboard or with pen and paper are just as good.
Example of an interactive wireframe created using Figma’s new AI Design tool
What automations need to happen behind the scenes?
We have our data and our interfaces, but we’re missing functionality.
Enter automations and workflows. They’re triggered by events, like user interactions or schedules, and then run a series of sequential actions.
Automation platforms like Zapier, Make, n8n, and Gumloop are all strong options for building standalone workflows. No-code platforms like Glide can connect to these platforms while running automations natively.
Try doing some diagramming of the workflows you need to create. This will help you choose the right platform for the job. (Miro and FigJam are good for this exercise, too.)
Example workflow diagram built in Miro
3. Developing & deploying your solution
You have your requirements, and you’ve designed a solution against them. Together that gives you a plan to work from, however tentative it might be.
The next big question: What platforms are best suited to your plan?
While I work with Glide, I don’t believe that Glide is the best choice for everyone. That’s why I encourage starting with a plan and prep work. It’s like building a house. You don’t just “wing it”. You start with the blueprint.
Other considerations to factor in:
Does it explicitly call out use cases like yours on their marketing site?
How does the platform handle user access and authentication (e.g. SSO)?
What’s their pricing model based on?
Where is data stored? How is it processed?
How much control do you have over the data? Can you easily import/export?
How does the platform handle versioning and backups?
Does the platform integrate with the tools/systems you use today?
What are the support options and SLAs?
Is there an active ecosystem/community you can tap into if needed?
This list isn’t exhaustive, but it should give you an idea of what to look for.
4. Documenting what you’ve built
Documentation is woefully under-appreciated, but it’s essential.
Documentation for yourself.
It covers how the solution was built, so if you have to walk away from the build for a while, your developer docs will help you dive back in. I keep my internal docs somewhere my colleagues can easily find it, like Notion or Confluence.
Documentation for your users.
Easily found and easily used. It might live in the solution, or where your users already reference, like a Slack Canvas or existing knowledge base.
Documentation for AI.
AI and agents are increasingly becoming an indirect interface for our users, so we need to account for how the LLMs interpret our docs.
5. Distributing it to users, in phases
We’re almost done!
With your solution built and docs underway, you’re ready to put it in the hands of actual users. If you have many intended users, try a phased rollout:
Phase 1: Early Testers (Alpha)
A small group. Stay close to them, gather their feedback, and iterate quickly. You’re going to knock out a lot of your user docs during this phase, too. I like manually reaching out with a personal invite.
Phase 2: Soft Launch (Beta)
Open access that users can opt into or apply to join. You’re squashing more bugs, polishing the experience, and systematizing the feedback loop. Build a form, include some screening questions, and work through that queue. Even if someone isn’t a good fit for your beta, you’ll have a targetable list of folks to reach for the next phase…
Phase 3: Big Push (Stable)
Announcements, releases. Development will continue beyond this point, but it’ll be through bug fixes, iterative updates, and new features. How big your announcements go will depend on what you’re building and who it’s for.
Closing thoughts
So, to recap…
Gather your requirements. What do users need to accomplish?
Create a plan. What data, interface, workflows will you build?
Get building! Choose the platform best suited to your plan.
Document your build. It’s context for yourself, your users, and AI.
Start sharing it. Get feedback. Iterate. Share with more people.
I love building custom tools and solutions for my community.
You see a need → you invent something → members use it.
It’s an amazing feeling. I hope you’ll give it a try. 🙏🏻