Hi, I’m RJ Jones! I work at Adalo as a Technical Support Engineer. I also work as a no-code expert, and run a development agency called Floss Tech. We’re a tech support company first, but we also do development with no-code using Adalo.
I started the business about four years ago, and we started out with no development at all. It was literally just tech support, and then we branched off into other business verticals like websites, apps, and products like that. I have three other developers that help me with no-code building, and then we have six technicians working with us for tech support.
Working as an Adalo Expert has been an incredible experience. I’ve worked with really great clients, and it’s been a good challenge to build no-code apps that help bring people’s ideas to life.
Here are some of my experiences as an Adalo Expert, and I hope they help you figure out how to work with a no-code expert, what to expect, and how to set yourself up for success!
When should you hire a no-code expert?
I definitely feel like that varies on your technical know-how. If you don't have much technical experience, I’d recommend hiring a no-code expert early, or for them to build the entire app for you. This is only in situations where, if you don’t have much experience at all, and are looking for a complex app that you may not have the time or skills to build.
It's harder for a no-code expert to come in and work on a project that hasn’t been worked on correctly because you have to undo what they're doing and find out what is going wrong instead of just starting the build. So there's a lot of troubleshooting which takes a little bit of extra time to understand what is currently happening within the application.
If you're tech savvy and understand Adalo well, but you want to incorporate something a little more intricate, maybe like a custom API, or a scheduling app, then I would say it’s a good idea to hire an expert to add additional features that are just a little bit more tricky.
In my experience with clients on Adalo, about 60% of the time, I’m coming in and helping people with something they’ve built already, and the rest of the time I’m building it from scratch.
I typically work with people that are stuck trying to implement an additional feature, and sometimes if they aren’t too far along the building process, I suggest starting from scratch to make things easier for everyone. Surprisingly, it actually decreases the amount of time I spend working on apps.
Getting started on a project
Here’s what the journey usually looks like for me: I usually start with a consultation, where if it’s 30 minutes or less, I don’t charge for it. During this consultation, I try to uncover what the potential client is building: their use case, the features they want, and their goal for the app.
Next, I put together a quote on the number of hours it may take to complete based on the scope of work. I usually add some buffer for things that could go wrong, or things that I know are kind of tricky that I might need to spend time doing research on.
When I send out a quote, I break it up into sections, like the actual consultation portion of it, then the wireframing work, the database creation, the feature, testing, and then the publishing.
That way I know how much time I'm putting into each part of the workflow, so we stay within the designated scope of work. I never start anything until I know we’ve both agreed on the price and the way the project is managed.
How I like to manage my no-code client projects
I like to use a tool called ClickUp to manage my work. It’s a handy project management tool. I create a task, and allow the client to add comments. I’ll usually add Loom videos of what I’ve completed so they can follow along.
A lot of people prefer to get on a call to review the work and features I’ve completed. I’ve now tried to get away from that because my day would be packed with calls and I didn’t have much time to actually do the work. If I had six or seven clients at a time, it would get pretty overwhelming. Luckily I do have three other developers that work with me and help me so if I do have a lot of calls in one week, I can delegate some of the other tasks.
I normally do one call a week with clients to give them updates and keep track of our work. In terms of a timeline, I don’t give anything less than four weeks to complete the whole build process. That doesn’t include testing or launch, which usually takes another two weeks. This is mainly because I don't want to overwork myself with work, I want to make sure I can always meet or exceed expectations.
During the testing period, I try to have my client test it as much as possible, instead of just me and my team testing it. This is because it's their vision and I want to make sure it's working the way they want it to work.
Once the app is launched, I usually work on a retainer model. Our clients are typically in favor of me running maintenance, they usually ask for it because they want someone to deal with things breaking or with additional features down the road.
How to determine whether a no-code expert and a client are a good fit
From the client's perspective when it comes to deciding which expert to go with, I definitely think the cost is one of the most important factors, the next is my expertise and experience. Some experts specialize in working with Zapier, some specifically work on design. And then, it’s definitely the time zone and language. Communication is really important when working with clients.
I’ve worked with clients in Japan for example, where there’s sometimes a 12-hour time difference and communication can be a challenge. We both have to wait at least 12 hours before getting a response, so that isn’t always ideal.
Another thing that would help make the relationship smoother is if they had a gauge of how much we charged (more specifically than the information currently on the website). Usually, clients talk to a few Adalo Experts before narrowing down on one. It’d be helpful for them to know what we charge beforehand, so they can decide if it’s worth scheduling a consultation call.
Most of the time, I don’t have to explain what no-code is, or any possible limitations associated with it. People do understand that it is not a fully coded app. They come in knowing there might be limitations, they may not know what those limitations are, but that’s where I help them. Clients generally choose no-code because of the cost, so they understand that there will be work-arounds.