AppFlows is a privacy-first online tool that helps you scope, estimate and visualise app ideas as fast as you can type.
I made AppFlows to help our clients here at Pocketworks. Most app ideas start with boring spreadsheets, and I craved a visual way to scope, estimate and explore ideas without getting bogged down in visual design.
It's a bit rough n' ready, but any feedback would be greatly appreciated.
It doesn't save anything to the cloud.
It supports markdown.
It currently doesn't using an LLM but I'm sure that will sneak in at some point.
One day, I'd like to have it generate wireframes using AI.
I've curated a list of tools below which I update regularly.
I've spoken to a CTO who are using no-code tools, so here are some views:
1. Cost - Will depend on compute power needed, but for internal tools that will be low.
2. You might want to pick something you are familiar with and is actively developed and accepting pull requests. A lot of the low code tools do allow you to write custom code anwyay, which is worth bearing in mind.
3. That's a tough one, some of these tools have a commercial model that runs alongside their open source model, which may help give some security. I remember that Facebook pulled their low-code backend tool many years ago, so just because it's by a big company, doesn't mean it has a long future.
NocoDB - Turn any database into a smart spreadsheet
Baserow - Create your own online database without technical experience
ToolJet - Build & deploy internal tools with minimal engineering effort
BudiBase - Build apps for your workplace in minutes
AppSmith - Build admin panels, CRUD apps and workflows 10x faster
Saltcorn - Point and click database web applications
Lowdefy - Build web apps, admin panels and BI dashboards with ease
Directus - Wrap your existing SQL database with a GraphQL+REST API and admin panel
Frappe Framework - Metadata-driven, full-stack framework in Python and Javascript
Basetool - View and manage all your data in one place like a pro
Rowy - Manage Firestore data in a spreadsheet-like UI
GDevelop - Free, and easy game-making app
PocketBase - Backend for your next SaaS and Mobile app in 1 file
NocoBase - Build internal tools in minutes
I run a mobile app agency like you and we do pretty well selling GaSaaS.
I'm a developer but have studied sales quite a lot over the last 10 years. The most important thing I learned is to find clients that fit you really well when it comes to skills, culture and budget.
To do this you have to give a shit and not be afraid to ask potentially off-putting questions. Stuff like:
"Are you sure you want to build this app, your business case doesn't add up so why bother?"
"Can you demonstrate you're in this for the long haul? There's no joy in building an app that fails, which is what happens if you don't budget to iterate your app."
"How come you don't hire freelancers or contractors, it will cost you less?"
Obviously I ask nicer questions too, but these are good "give a shit enough to risk losing the sale" kind of questions.
We once landed a $mm deal because I told a CTO to his face that most of his teams were probably incapable of accurately describing the technologies they use and how/why. 90% of the time it works every time ;-)
Interestingly, I've found that tools become less important the more you nail your purpose, culture, communications and processes.
For that, the Traction book would get you off to a very good start in implementing your company "Operating System".
I do understand your interest in tools though, but I spent far too long obsessing over tools in my business. Perhaps it's because I'm a software developer and I wanted to believe that tools could fix the problems, rather than facing up to the more human challenges.
Right now our 15-person business uses Notion, Slack, Google Docs, Figma Jam, Semrush and Productive. These cover all the things you mentioned.
I run a small-ish dev shop ($1.5m revenue) and there are a lot of things I wish I knew back in 2012 when I started.
1. Finding clients is hard. Think hard about what an awesome customer looks like and then figure out how to reach them. This is the most important thing IMO. I'm reading Standout of Die, it has good advice on this.
2. First attempt, I started with about $40,000 and blew it all quickly as I didn't have enough sales. Better to get the sales first then grow the rest. You can be transparent about this with potential clients.
3. If your costs are $400,000 a year, and you'll sell 44 weeks of the year allowing for holidays, sickness and wiggle room, then you need to sell $9,000 a week to stay in business. If you want to make 25% profit then you'll need to sell closer to $500,000 a year and $11.3k a week.
4. I'm in the UK, we pay someone to politely chase clients for payment. This was a game changer. Most agreed to pay monthly but never do without a good bit of nudging.
5. As for tips... There are so many good books and courses on building and running a service business, I wish they'd been there when I started. To name a few.
- Jonathan Stark.com - Hourly Billing is Nuts
- Gareth Healey - Standout or Die
- Jason Swenk - Agency Playbook
- Blair Enns - The Win Without Pitching Manifesto
- Blair Enns - Pricing Creativity
- Traction - Gino Wickman
Running a dev shop can be incredibly rewarding and fun, especially if you love the work you're doing. Building a business will be like learning a whole new career, so don't underestimate the learning curve the number of mistakes you can make (if you're like me haha). It's great that you're asking for advice, it will save you some headaches :)
Not at all, we just finished our financial year and it was 14% operating profit.
The previous year was 29%, but last year was lower as I made some expensive decisions during the COVID period. Basically, I grabbed all the revenue opportunities I could without too much concern for profit
Would love to know that as well. I have worked with few agencies as a contractor. From what I heard it is very hard to have a decent margin doing software dev work unless you have offshore subcontractor connections or an offshore office. When you have a downturn it could be brutal with an onshore team.
You're right about the downturn, it's impossible to run a team for long without a full order book. That said, I think you'd have this problem for an offshore team too, perhaps with a much longer "sat on hands" cash runway.
I have a friend who's set up an offshore team and he saves 70% on developer salaries from what I can infer.
We employ within Europe and the UK, our average dev salary is around $65,000.
I don't think you are saving much by hiring outside of Europe or even UK. Many people had their fair share of trouble with Ukraine. Even a qualified latam dev's full time salary averages out at USD 30-40/hour.
tobinharris thank you so much for your great comment and advice! I imagine it is very hard managing such a large agency. I'll take your advice into account when starting.
We do this. We're only a small 12-person software agency, we have two Elixir developers right now.
When we hired the 2nd, we looked for someone who had good knowledge of Node, Rails, Laravel or whatever and were excited to learn Elixir/Phoenix. Then they completed a Udemy course and started practicing. It worked out pretty great!
1. A company playbook writing tool that helps you document team and company processes. It gives you a nice online browseable playbook, along with .epub and .mobi download.
2. Adding more advanced features to my https://yuml.me UML tool, including text formatting, UML packages, and a more succinct DSL.
3. A contract e-signing tool that doesn't suck on mobile. For some reason, every digital signature tool I use feels yucky.
4. A tool that lets you write out user stories and converts them into example mobile wireframes by parsing the text. You can also do point estimations for relative sizing.
I made AppFlows to help our clients here at Pocketworks. Most app ideas start with boring spreadsheets, and I craved a visual way to scope, estimate and explore ideas without getting bogged down in visual design.
It's a bit rough n' ready, but any feedback would be greatly appreciated.