Software in general: the client only knows exactly what they want, when you’ve given them a prototype of what they said they wanted, only to have to change everything.
So collab, bounce off ideas, and change it all anyways.
You’re going to learn as you go but to answer your questions.
[quote=“hergin, post:1, topic:310486”]
How do you, experienced bubblers, select your clients?[/quote]
Current workload, complexity, client feel, budget, client readiness with scope docs/biz vision, I personally prefer projects where the client has full business plans & scope docs laid out. Many times I turn clients away because they aren’t ready and just have concepts in their mind and nothing on paper, I provide them a pdf “how to successfully turn your idea into a reality with your developer”. That goes over how to scope their project, UI/UX, expectations, how to differentiate between a MVP and a V1. Why building lean and letting your customers tell you where to head is important over overdeveloping, and a few other things. Many times these prospects return in 30-90 days ready to build. Those that don’t aren’t my ideal client.
Scope document is almost 100% necessary, without it you’ll end up in a cycle of disagreements & expectations that don’t line up. I almost always help them lay out the detailed scope document if they are coming from just key point ideas. (After deposit only)
As most of the projects that require full UI/UX are MVP builds I give them a few options.
1: They bring us the UI, we discuss it and anything that’s more complex to implement in the bubble builder I recommend an alternative verbally.
2: We build the UI and I price this in based on a few questions to get their vision laid out, if they are MVP it’s usually pretty boiler plate to keep it budget friendly and I explain their v1/v2 can have a full UI/UX overhaul but right now the important part is to have the MVP & start cashflow so revisions will be based on our discretion. After 1 round we charge additionally hourly.
3: if it’s a continuation project we use their base & elements to expand.
Personally we are usually kind of strict because we don’t want to turn 4 week projects into 8 week projects of revision cycles.
Review the API to ensure it’s a standard implementation or if it’ll need done with plugin actions or something more complex, get an estimated time it’ll take to implement, base it on your hourly rate.
I wonder: