Simple, Lovable, Complete, or SLC, is a product framework introduced by Jason Cohen. It asks you to release something small that people want to use and that finishes its intended job. For a first app, I use it to keep the promise narrow while making sure the user can actually get the promised result.
I say “ship ugly and fast.” I also say “build something people want to use.” Those ideas belong together when ugly means visually basic and the useful part works.
A rough logo is fine. A save button that loses your work is a problem.
What does Simple, Lovable, Complete mean?
Cohen’s original SLC essay describes three qualities:
- Simple: keep the product small enough to deliver quickly.
- Lovable: give people a reason to enjoy or value using it now.
- Complete: finish a useful job within the scope you promise.
The framework comes from Cohen. The app examples and release checks below are my practical application for people building their first version with AI.
What is the difference between SLC and MVP?
MVP means minimum viable product. The Lean Startup methodology uses it to begin learning about a product and its customers quickly. SLC puts explicit emphasis on the customer’s experience of the first release.
I wouldn’t assume every MVP is broken. The useful question is whether your chosen approach helps you learn while giving users something worth their time.
| Planning question | Learning focus with an MVP | How I apply SLC |
|---|---|---|
| What do I need to find out? | The assumption the experiment tests | The same assumption, plus the result a user receives |
| How much do I build? | Enough for the experiment | Enough to finish the narrow promised task |
| What do I inspect? | Evidence that changes the next decision | That evidence and where the experience becomes frustrating |
| What can wait? | Work that doesn’t help the experiment | Extra use cases, decoration and optional automation |
You can use both perspectives. Define what you need to learn, then make the part people use worth using.
What would an SLC app look like in practice?
Imagine a reusable packing checklist for people who regularly take short work trips. This is a hypothetical product, not a case study or a claim of market demand.
The promise is: “Start from your usual list, adapt it for this trip and check items off while packing.”
The first version could let someone create a template, copy it for a trip, edit items, tick them off and find the list again later.
That sounds small. Good. Now use it for an actual packing session.
If changing one trip changes the reusable template by accident, the basic data behaviour needs fixing. If you can’t tell which items remain, the screen needs work. If you have to recreate the list every time you close the app, the main benefit disappears.
Those fixes belong in version one because they protect the result.
Flight booking, social sharing, AI travel advice and a wardrobe catalogue can wait. They are separate promises, each with its own work and risks.
How can a simple app be lovable without elaborate design?
Pick one moment where the user should feel relief and make that moment easy.
For the packing app, that might be opening a saved template and seeing a familiar list ready to adapt. Clear labels, readable text and an obvious next action matter more than animated luggage.
Watch someone use the app without explaining it. If they hesitate, ask what they expected. If they finish the task, ask which part felt easier than before. You are looking for a specific improvement you can preserve.
I would spend time making the remaining-items count understandable before designing a splash screen. Both are visible, but only one helps someone finish packing.
How do you know whether version one is complete?
Write a small set of scenarios and try them on the actual version you intend to share:
- A new user opens the app and creates their first list.
- They correct an item entered by mistake.
- They leave and return, with the expected information still available.
- They finish the task and understand that it is finished.
- Something ordinary goes wrong, such as an empty input, and the app explains how to continue.
Add checks for the capabilities your app actually uses. If people sign in, test access and recovery. If they pay, test the full purchase experience. If you store personal information, make sure the access and data handling are appropriate before inviting people to rely on it.
My first-version feature guide helps you decide which capabilities belong in that promise. The existing 20 things your vibe coded app needs to hit $10K MRR post gives a wider view of running a product. Use it according to your app’s needs, not as an instruction to add every feature to every prototype.
Does ship ugly and fast mean you can skip testing?
No. It means spending less time on things that don’t affect the first useful result.
Skip the custom illustration if it delays sharing the app. Use a clear default layout. Start with one export format. Choose one supported platform if that serves the audience.
Then test the actual workflow. Speed comes from fewer promises to implement and verify, not from pretending verification is unnecessary.
For the building process itself, start with my beginner vibe coding guide. If you are still unsure whether the problem deserves a product, validate the idea first.
Frequently asked questions about SLC
Who created the SLC framework?
Jason Cohen introduced the framework and explained it in his essay published on August 22, 2017. Credit him when describing the model. The term is a product development concept, separate from the AI app builder called Lovable.
Is SLC an alternative to MVP?
Yes, it can be used as an alternative way to frame a first release. I find it useful when “minimum” has become an excuse to give users a half-working experience. You can still run experiments and measure behaviour while applying SLC.
Does complete mean every feature is finished?
It means the task you promised can be finished. In the packing example, copying, adapting and using a list should work. A trip-booking feature doesn’t belong in the definition of complete unless booking is part of the promise.
Can an SLC app have bugs?
Any software can have bugs. Decide whether a known issue prevents the promised result or makes it unsafe to rely on. A cosmetic spacing issue and a defect that deletes saved work require different decisions. Don’t hide a serious limitation behind an early-access label.
Should I add AI to make the app more lovable?
Only when it improves a result the user wants. The packing app might work well with editable templates. Generating a list isn’t automatically better if users then spend longer checking it than they would adapting a familiar one.
How long should an SLC first version take?
That depends on the task, platform, integrations and consequences of failure. Choose a small time budget, then reduce optional scope to fit it. If the core task still cannot work within that budget, reconsider the first promise or run a simpler experiment.
What should I build after the first release?
Find the recurring obstacle that stops the intended users from getting value. Fix that before collecting unrelated requests. If the existing version keeps doing its job, maintaining it can be a better decision than expanding it.
Start by writing the one result your first user should get. Make that work. Put it in front of someone who cares about the problem.
Sources and further reading
- Jason Cohen: Your customers hate MVPs. Make a SLC instead., the original framework.
- Eric Ries: The Lean Startup methodology, the learning purpose behind MVPs.