How To Build Any App For $10K + Productising No-Code Development (Business of Bubble)

Jobs / Freelance
1

Hello folks!

My name’s George - I run Not Quite Unicorns, a new low-code development agency based in the UK but serving clients around the world for the last 6 months or so. After successfully working with these clients, I’ve decided to take the agency in a different direction. I’ve been working to see how no-code development can be streamlined and improved after identifying a lot of pain points from both clients and other agencies or freelancers.

Is this just an ad? Depends who you ask! I’ll probably speak to a few clients as a result of this post, but it is mainly for other freelancers + agencies interested in pursuing a similar model for themselves. If it feels like a compelling sales pitch, then that should be enough to make you consider implementing it yourself :wink: I’m putting this here as a resource and perhaps a post for discussion so that freelancers/agencies/clients can all improve how they work and increase satisfaction for all stakeholders.

So, what am I doing? Fully productising Bubble development from initial build to ongoing development. Fixed prices for everything, fixed timelines - yet with even more flexibility than standard agencies.

The measurable results of this model are:

  1. Hire conversion rates (as clients know exactly what they’re paying before they even meet you)
  2. Better client satisfaction (the whole process is so much more efficient after cutting out bureaucracy)
  3. Better developer experience (less time scoping, negotiating, and other admin - more time working directly on an app)
  4. Faster launch and more agile development (pre-defined budget limits the project scope and forces founders to launch lean and then expand based on user feedback)

The structure of this post is as follows:

  1. break down the problems with no-code development freelancer/agency structures right now
  2. explain why I building any app for $10K
  3. explain why unlimited development subscriptions are a great option in low-code development
  4. explain how this works as a multi-developer agency
  5. job opportunities / hiring :grin:

Throughout this post I’ll use no-code and low-code interchangeably so don’t get thrown off by that.

What’s wrong with no-code development now?

The no-code development landscape consists of two main types of workers - freelancers, who do everything themselves or sometimes subcontract for small items, and agencies, who have a moderately sized or large team of people working on apps.

Too much bureaucracy - Bureaucracy

  • Scoping takes too long and is a pain in the ass for clients and agencies.
  • You talk with the client, write a detailed scope, send it, only to find their budget is half what you expected and they want twice as much included.
  • From the client perspective, you have to enter talks with many agencies, and it can even take weeks to get from initial contact to final scope and quote.

Lack of flexibility - Flexibility

  • I’ve seen too often from talking to members of the forum and from clients that a client will have a vision for their app, and build it out, only to discover the customer wants something slightly different.
  • By this time, the app has already been built, and the money has been spent.
  • Want development after the launch of your app? You probably have no idea how much that’ll cost until it actually happens and can find yourself paying way more than you expected.

Assessing quality of agencies and freelancers - Quality

  • It’s really hard to assess how good an agency is if you’re not proficient with Bubble yourself.
  • They might have a pretty front end with poor database design or build up technical debt by taking shortcuts. I learned this seeing some pretty templates on the marketplace which had zero privacy rules and very strange database structures / workflows. I’ve seen 7 figure VC funded companies who hired freelancers (and even agencies) with zero privacy rules configured and inefficient workflows.
  • Some agencies will rigorously stick to their pre-designed templates or frameworks so they will guide clients towards a specific feature/implementation when the client wants something else. For example, some templates do database searches to create a header menu for the sake of building efficiency which means the header doesn’t load immediately with the page. Whilst there’s a place for templates, they should be kept lean and they should never be used to try and mould a client’s vision to fit your pre-existing template.
  • If you look for freelancers on the forum, you end up with like 20 DMs from people that barely speak your language and have no profile or forum activity so you don’t even know where to start…

Too expensive, not lean - Price

  • No-code development is still too expensive, even though it’s way cheaper than traditional development
  • No Bubble MVP has any business being more expensive than $25K even if you’re working at $100/hr. Seeing agencies offering pricing ranges into the 6-figure range is absolutely wild. What are you paying for? Things you didn’t ask for but got anyway - wireframes, designers, UI assemblers, QA, project manager… (more on that later)
  • These overheads jack up the price immensely when it’s not necessary. Pretty much all Bubble developers can assemble UI themselves. Design is a little different - for example, actually ‘coming up’ with designs isn’t my strong point but I can replicate them perfectly well, so I subcontract design if it’s really necessary. But most apps have simple dashboard or listing pages where there’s so much inspiration on sites like Dribbble that you can just replicate it yourself in Bubble.

The pain points of ongoing development

There are a few problems for clients with respect to how ongoing work occurs in no-code development:

  • costs unclear until you request a quote for a new feature / update
  • if you get a retainer it’s a significant outgoing for a service that you might not even use
  • lots of admin and discussion required for each part of ongoing work (can be like doing a lot of mini-scopes)
  • request → scope → quote → (negotiate) → confirm → implement → feedback → deploy → get paid

Build any app in two weeks for $10K.

How am I trying to solve this?

  • I will build any app for $10k. It’s dead simple. Improving: Price and Bureaucracy.
  • Clients know the price up front, there’s no missed expectations, and you filter out anyone with an unreasonably low budget so that you can focus on a smaller number of high ticket clients.
  • I hear you - “but George, some apps will take way more time than can be justified by $10k!”. I respectfully disagree. Any app can be slimmed down enough to create an MVP. It might not have every feature you initially wanted immediately, but that’s not a bug - it’s by design, which leads me onto the next point.
  • Design the scope to meet a pre-set price, not the other way around. Improving: Price, Flexibility and Bureaucracy.
  • This pricing model encourages lean development. It encourages clients to deploy their product/internal tool/web app and get feedback from real users. The client can then get feedback from these real users to either validate or modify the product offering. If it fails, it fails more cheaply, and if it succeeds, you get explicit guidance on which direction to take the development in. Improving: Price, Flexibility and Bureaucracy.

Unlimited development, pause/cancel anytime

For ongoing work, I’m now moving to an unlimited development model (similar to designjoy.co for example). Unlimited development? How does that work?

The model works like this:

  • Client requests app for $10K. Define the exact project scope with client and build within 2 weeks.
  • If they need ongoing work to extend the app, the client subscribes to a monthly ongoing development plan.
  • Client can pause/cancel any time
  • The client can make unlimited requests
  • Only a certain # of requests are worked on at one time
  • Average turnaround of 24 (business) hours for data/text changes, 48 hours for features and sections, and 72 hours for pages or complex features. Of course, larger updates can be completed as fast as can be reasonably accomplished.
  • Client adds request to queue → Implement request → Client approves request → If good, deploy, if needs revisions, revise. As soon as a client approves the request, the next request in the queue will begin work.
  • request → implement → feedback → revision or next request

This is a model that is uniquely possible in low-code/no-code development. That’s purely because low code facilitates low turnaround times as it is efficient, and there’s really only one developer working on an app at the time. Compared to traditional code, you don’t need to consult with everyone else working on the project to ensure no breaking changes.

This model requires the following from the freelancer/agency:

  • fast turnaround times, so the client gets their money’s worth
  • ability to work on assumptions - there’s no point doing this if you have to ask your client about every little detail. You’ve worked on dozens of projects, you have a grounding in the real world - you can work out what they need and only ask for clarification if really needed.
  • design competence - there’s no wireframing or prototyping here unless the client explicitly asks for it. Just do it. Create it, do a good job, and you likely won’t need any revisions. We avoid designs and wireframes unless the client asks for it as we should understand their vision enough to make reasonable assumptions about what they ask for. For complex pages, we design it in Bubble and send a quick screenshot for approval by the client.
  • all rounder - let’s say a client wants a ‘how it works section’. They might not specify the exact specific features or the exact wording of this section but you should be sufficiently well acquainted with the app, its users, and the client to know which features to highlight and give your best shot at the wording, because most of the time it’s good enough.
  • be good - if your client needs revisions every time, it will be inefficient and no better than traditional pricing models. Get it right first time.

It requires the following from the client:

  • ability to explain the request clearly so no follow-ups are necessary most of the time
  • common sense when planning whether a specific request is a minor change / a feature / a page/complex feature

You might argue that there’s a conflict of interest - the slower the developer is in turnaround times, the less work they have to do and the client pays more for less. However, if this happens, the client will just unsubscribe or pause their subscription (because the subscription is completely flexible). The developer is interested in retaining each client for as long as possible, so will strive to provide the best possible value.

Why flexible subscriptions are important

Is this a retainer? No. There’s no minimum terms. No obligations on the client’s part. If the client doesn’t have any work to do on their app they can pause their subscription in a click or two and save it for a time they do have work. If they’re finished with the development, they can cancel it.

There’s no risks for the client and they get development on demand. The developer also grows a defence against the feast/famine problem.

Scaling as an agency

Currently, NQU is just me and anyone I choose to subcontract for short term work. I am only taking on a limited number of clients myself as otherwise the workload becomes too great and you cannot offer each client the perfect service they deserve.

However, I do want to extend my offering to more clients as I believe that it’s great value for them whilst being better for myself - it’s just better to work with a smaller number of higher value clients.

To extend this model to a multi-member agency:

  • each developer is assigned to a particular client. No project managers, designers, UI assemblers, or other wastes of space. Client talks directly to the person working on their app. Save time for the client and developer and reduce miscommunications.
  • the developer must be competent and able to operate independently. It’s all about hiring a developer that does not need to be watched carefully as they can be trusted to deliver a quality product.

Closing Thoughts

For those of you considering joining the NQU team, know that our primary emphasis is on quality, communication, and adaptability. We’re looking to build a team of forward-thinking developers who are excited about the future of no-code and are eager to shape it.

To all the freelancers, agencies, and aspiring app developers reading this (well done for making it this far), whether you agree with my perspective or not, I’m keen to hear your thoughts, even if you wildly disagree!

32 Likes
2

Great post George. For starters, I find it outrageous that any agencies/freelancers charge in the 6 figure range for no-code development only to end up using templates and poor data structures/privacy. It defeats the whole goal of nocode which is to test ideas faster and cheaper. I had a client telling me yesterday how he had spent over $300k for his former MVP and how he achieved the same thing with me for under 10k. It made me think a lot about the value I was offering him both in time-saving and costs.

I also appreciate the flexibility your pricing offers for recurrent changes as honestly…almost every project requires some change at some point. As a freelancer seeking to operate as an agency myself…I would seriously consider this and I am curious how the industry reacts to this…

4 Likes
3

I think your model is great and game-changing in one particular way. From a business’ perspective, they can calculate the cost of their website (which usually is their “product”) and know their “all-in” costs before even starting development.

In addition I think your model solves client’s 2 biggest fears:

  1. Will my website work?
  2. How much will it cost me?

I’m a big believer in rapid iteration, so to highlight what @incomdies is saying above, going to market quickly rather than spending $300k and waiting a year to launch will lead businesses to success.

3 Likes
4

It’s so easy to get people on a call if you can tell them how much it’ll cost without having to exchange any information!

The first of those is solved by social proof and an impressive landing page - I haven’t actually put any social proof / past work on my site yet as I’m still in the process of collecting client testimonials, but it’s amazing how far a pretty landing page can take you.

The second is harder to solve and is what I think I’m doing a great job of tackling. It filters out really low budget stuff so nobody’s time gets wasted (client and freelancer both), and engages higher ticket clients with a pretty compelling price point.

2 Likes
5

thanks George for Sharing

6

Okay, so not building any app for $10K…what exactly would you consider to be features of an MVP versus a complete app for a marketplace as example?

For me, working with clients who are after a true MVP, it usually costs less than $6K USD and for full apps with all the necessary features/functions to have their existing business continue to operate with the automated efficiencies the app provides, those apps range between $8K and $12K on average.

In my experience, clients do not know how to request clearly because they do not necessarily have the technical know how to elaborate on features well enough to get the complete picture. For example, a client who requests a notification system, all they may know to request is, I would like a notification system, but the rub is, how complex of a notification system do you need and how do you intend to use it.

Does the notification system require the sending of links via email or SMS or push notifications in order to allow the user to click the link to be directed to the exact location of the app where the event notified is (think a new booking, open the dashboard to booking section, show only the new booking in question)…or does this notification system only need to provide an alert on opening the application that something happened since their last logged in session (like a dropdown that says you received a new booking, which then requires the user to navigate on their own to the bookings area and search to find the new booking).

There are a lot of different types of features that can have various levels of complexity that require the developer to be fully aware of the clients specific use case for the feature for the developer to build the app properly from the start by laying down the foundations for the feature to perform as required.

For me, I usually don’t find that type of information from the client until we have a meeting to discuss all the requested features and I ask the questions that I from my experience and expertise, know to ask that the client might not have known to express.

Additionally, it is incredible the disparity between what client expects to be a minor/major change. I’ve asked clients in the past, how long do you think that will take, and on both sides of the spectrum, they are usually wildly wrong. I’ve had clients indicate a change, in their opinion may take 4 hours, while in my experienced knowledgeable opinion, it would only take me 10 minutes. And the same on the other side, what they think is 2 hours of work is maybe 10 hours of work.

It is very hard for non technical clients to have any reasonable expectations of how long something takes to develop, as they usually have never developed something themselves. It is like asking a four year old, how long does it take to bake a lasagna. Likely the answer is just some made up random figure.

I see the subscription as a bit worse than a retainer. In fact, for my clients, I don’t require a retainer or a subscription to remain at their disposal for future feature implementation or bug fixes. Most of my clients that come with feature implementation requests need to be treated the same as clients coming for the first time with requests to build their MVP/App, which is, I need to put them into a working queue so that I do not overload myself and over promise and under deliver to all clients. For bug fixes, those are usually quickly and easily fixed and often enough take less than an hour, so I can be flexible enough in my day to day that I can jump onto those bug fixes ASAP.

In the end, every developer/freelancer/agency will come up with a pricing strategy that they feel may uniquely position them to stand out from the crowd, or ultimately simply be better for the client. I applaud you for taking the time to carefully craft your offering and sharing it publicly. I’ve seen some other agencies offer a similar subscription based type of service, like $2,500 per week of development with unlimited feature requests, or on-going development support for $500/month plus hours spent (ie: there is a flat $500 a month charge to remain available for the client and then the normal hourly rate to provide the requested development services or bug fixes).

What I have found that works best for me and my clients.

  1. Client requests development services and price quote with a single line summary of the project.
  2. I reply with a request for them to supply me with the complete project scope, listing all requested features.
  3. Client takes the time to create the list (which is then readily available to share with other developers/freelancers/agencies they may be requesting quotes from).
  4. I provide a time/cost range estimate. This is essential to make it so the client has a solid understanding of the maximum the app will cost as well as a minimum figure. This allows me to insulate myself from any unknown hiccups that might occur (Bubble editor slowing to a crawl, bugs in API providers - you wouldn’t believe the number of Bugs I’ve uncovered in API providers like Zoom, Microsoft and Google).
  5. Client is satisfied with the maximum price of the range and schedules a time to discuss in detail the project scope and each feature. This part is essential to getting the project off to a solid start to have a satisfied client at the end of the project. As mentioned, clients usually don’t have the technical experience to fully articulate the features they are requesting, so this meeting allows me to ask the questions they never knew to ask themselves, so that I and the client have a complete understanding of exactly what the feature requires.
  6. In the meeting I reassess the original time/cost range estimate if need be. Normally this gets reassessed down, as during the meeting I can expertly advise my clients on whether or not a feature requested was actually needed, or could be slimmed down to reflect their goals (ie: are they building an MVP or do they need a full blown app to operate their business).
  7. Client pays the non-refundable deposit (used against the final invoice and to insulate myself from a client agreeing to start a project and backing out which causes issues in my careful planning of my working schedule with great focus on not overloading myself) and I place their project into my working queue. Depending on how busy I am the wait is typically 2-4 weeks.

I provide my clients with between 10-20 hours of development a week each, and I take on no more than 2-3 clients at a time. This allows me to stay focused on each clients project in a hyper focus manner (ie: no more than one project worked on in a given day, and spend no more than 2-3 days on any given project in the week). If I can not get myself into a hyper focus state, I am doing a disservice to my clients. I also, while developing, turn off the phone and any computer notifications as each time a ding goes off and my eyes are averted to a notification or my phone, it removes me from my state of hyper focus and causes a 5-10 minute delay in development speed as I need to try and reorient myself to what I was doing prior to the distraction.

It is always interesting to hear from others and share our approaches to development and how we handle client work. I’m sure a ton of up and coming developers find this useful in crafting their own strategies as just starting out and trying to figure out how to work with clients can be confusing for some.

8 Likes
7

Great feedback :grin:

For a P2P marketplace, it might include (along with the standard account management and other things you’d expect):

  • listing search with filters
  • promoted listings
  • escrow
  • reviews
  • admin analytics
  • real-time chat

What might not be included (without cutting out one of the other features):

  • dispute resolution (an edge case that can be resolved manually at first)
  • seller analytics (they can use Stripe Express initially)
  • discount coupons/referral program

That’s why you can choose your clients. If you know they’ll be difficult to work with under this model, turn them away - it’s not for everyone. If this is raised during the MVP scoping, that’s something that I would be clarifying with them to put into the final project scope. If it’s during the ongoing development phase, if they don’t give more detail, I give it my best shot, and they can get any more changes after.

We still have that meeting - but for the most part it’s meeting → project scope same day → one more meeting for additional questions and a couple of revisions → project kickoff.

I might not be understanding correctly but NQU doesn’t either. For example, after the app handover, if they need nothing for 3 months, they’re not paying any subscription (or anything to me for that matter). If they’re then like, ‘hey, can you add a new filter X on the search page’, they can subscribe to the $999/mo plan, wait 48 hours for me to turn it around, and then pause it, saving the remaining amount for later. This avoids me getting tied up negotiating (and working on) dozens of $50 requests! If they have more features, they can just add them to the queue and keep their subscription going.

Of course, but that’s not a problem. It’s the developer that decides whether it’s a minor/major/complex change and they can split a feature into chunks as necessary.

This is an interesting one. Personally, I do bug fixes free of charge for 30 days after project delivery, and critical ones for longer. I obviously can’t guarantee all bug fixes permanently as at some point you have to wrap a project up as complete.

This is one I’d disagree with (although it obviously works for you). I find that a client writing a highly detailed project scope is a barrier for them. Instead, I’d rather put the burden of writing a detailed project scope on myself to minimise the amount of work required from them → increase conversion rate.

Do you mind sharing what deposit % you do? I run with 30% at the moment, but don’t here much from other developers about what they go with!

Absolutely! Your post is a great read.

I do wish there was more ‘business of Bubble’ posts on the forum because I find them really interesting but obviously the people/agencies that are successful are kind of disincentivized to share (hey, if it works great why would you want someone else to try and steal your thunder?).

3 Likes
8

For me, a bug fix is treated the same as me testing while building. If I built something and tested it 10 ways to Sunday and I didn’t find anything wrong, it doesn’t mean that once the client and users start to bang on the app that it is not possible we could uncover an issue I was not able to find during my development/testing.

It’s not a highly detailed project scope. Just something that has more than one sentence. Like something that has one sentence for each feature they are requesting.

$500 USD.

This will be really interesting to see how that works out in your favor or strongly against. I could imagine clients expectations might differ from yours. For example, if it is not a simply please add a new filter (ie: 15 minute task) and instead it is ‘please add new listing type such as jobs’, which would require a lot more than just 48 hours worth of the $999/month subscription, and likely be something that if priced out on it’s own, could actually require about $999 worth of your hourly rate, would you be making the client wait the full month for that new feature or push it out as soon as you could get it done, like in 10 hours (which if you charge $100/hr is $1,000 of hourly time, but only 2 days worth of work, so 2 days of the subscription = $66)

9

Haha, I have a different problem - I can’t focus on one project for an entire day!

10

Gotta try to get into a flow state or hyper focus

11

Sometimes it happens (especially if it’s a build I’m really interested in) but it stops in two main situations: reloading the editor, and dealing with the PayPal API :laughing:

I mean, that seems pretty straight forward. If their site is set up for say, car listings, and they want job listings too, it’s a case of adding an option data or data type for a high level category (car/job listings), bulk modifying the listings to set all the old data to the Jobs category, adding a new filter to the listing page, adding the relevant subcategories, and adding a category dropdown to the manage popup. Complex feature, but really just takes a couple of hours of the 72 hour turnaround.

I do understand your point though. If it requires more than the 72 hours for a ‘complex feature’, it’s likely a combination of smaller features. There’s a bit of a law of averages thing where sometimes you’ll get requests that work and some don’t, but it works out in the end and you benefit from the relatively more consistent subscription income (as most clients don’t choose to pause/cancel).

By the way when I write about my experiences with this model with clients, I’m speaking about 3 I’ve been doing ongoing work for over the past month and a half or so. Obviously not a huge sample size, but still reasonable to get an idea of how things work in practice!

1 Like
12

Thanks George for sharing this. Whenever I finish a project for a client, I always struggle with how to charge for a new feature request. Should it be a fixed rate, hourly, or a subscription (which I’ve never tried)? However, these discussions are really helpful, and I’m starting to understand how to charge in a way that benefits both freelancers and clients.

3 Likes
13

Going to close applications for this on October 1st.

Please follow the instructions or you’re not going to receive a response. Thanks so much to everyone that has :sunglasses:

1 Like
14

Exactly. This is why Bubble devs should not fear AI app builders

3 Likes
16

George, intresting post for sure. Have you considered dividing up your team by disciplines? In my full-time work (not as a bubble developer), I sit between the business and the developers where I ensure precise requirements are provided. With my business degree and consultant certification, I saved our development team many hours chasing unclear requirements. I am not great at Figma and I am likely only an average no-code developer but I, and I am sure some members of your team, excel at consulting with clients to get well-defined scope documented. I am wondering just how much of what is causing you to change your approach is not having someone up front document clear requirements or explain to the client the importance of clear scope before work can begin.

3 Likes
17

That’s a good point. My response would be that in a small agency (1-5 people) it’s just not feasible to have someone specifically dedicated to scoping. Of course some area better than others and you can put them on that job but generally if it’s one person working on the scope and the build then there’s a greater degree of alignment between the goals of the client and developer. It also allows the developer to manage the project as a whole - requests don’t need to go to PM → developer → PM → client and allows a lot of efficiency to be gained there and improves the client experience by reducing risk of miscommunication + the speed of iteration :slight_smile:

What I mean about the scope being a barrier for the client is that there will be many high value clients that we want to take on but just don’t have the time or the skills to know where to start on a project scope. By taking as much of that responsibility off of their shoulders and onto us, it makes the client’s life easier → higher conversion rates (and ties into our philosophy of making sure the client can for the most part leave us to it without having to manage the project. Just tell us what you want, pay us, and we’ll give you the project in two weeks!)

18

@cyclesblood, so you’re saying you have people skills?

Sorry, friend, but based on how you described your job, I simply couldn’t resist. I respect the hell out of the role, though, because no lie, I used to do literally the same thing.

5 Likes
19

:rofl: :rofl: :rofl:

20

That is an interesting view on AI as I’ve never thought about that limitation from the user, definitely makes sense.

21

Comment on this post to extend the discussion of this payment model.

I’m sure we can all agree starting a productized agency is one of the ‘hottest’ topics out there for Webflow/design requests. You now see these pop up everywhere, especially since the success of Brett Williams. So, very interested to see how this goes for a Bubble agency. Good luck!