What I learned spending $40k and one year launching my app.

[Hanabi]

OP hasn't been back to the forum. Great insights for sure.

Make sure you find a strategic partner when you launch an app.

He's probably busy hustling on his Fastlane venture. Anyways just in case if he comes back, he'll see everyone's appreciation.

Can you please elaborate on "strategic partner"? If you mean a partner possessing app development expertise, I have one.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[AppMan]

Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)

Good efforts, also you could have another option is to hire on shore developer and manage him directly, if I have enough money I would do that, but for sure it will be too expensive, also most good developers who could deliver will not work in single person business they prefer big tech companies.
Glad Adalo worked for you, in my case my app has some non standard features that no code platforms cannot fill the gap , also I ll loose some performance and granularity by using them.

 

[Felix Nachem]

Thanks for sharing.

 

[Velo]

Excellent OP.

A long time ago, in a land far, far away, I made the mistake of paying a "web design agency" because I thought "lol, the websites I build won't be good enough to attract clients/customers." $10K down the drain. $10K that could've gone to ads, marketing, or hiring marketing contractors.

Finding reliable help whether in the form of contractors or employees will always be a crapshoot ("keep trying until you find the right people"), unless you are amazing at reading people right off the bat (I am certainly not).

I also 100% agree that keeping your cash OUTflow to a minimum is absolutely essential, since the initial marketing phase can take anywhere from 2 months to 2 yrs and will heavily tax your available resources.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Ellenit]

Thanks for sharing your valuable experience. Wish you lots of success!

 

[Yula]

Thanks for sharing!

 

[GiacoQ]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Guardando indietro, avrei prestato maggiore attenzione al social media marketing non a pagamento, il tipo in cui interagisci direttamente con gli utenti. Ad esempio, avrei seguito le pagine di Instagram e Twitter con un elevato coinvolgimento tra i musicisti (es. XXL, Murda Beatz ) e avrei interagito con i commentatori nei loro post. In secondo luogo, avrei dovuto creare connessioni nei forum online: ci sono molti subreddit davvero buoni per diverse nicchie musicali che avrebbero potuto darmi un feedback davvero prezioso ed essere un'ottima fonte per i primi utenti. Probabilmente puoi applicare questa strategia alla tua nicchia.

Preziose relazioni con gli utenti
Anche se ho creato un pubblico decente per Artyst, il mio principale rammarico è di non offrire valore molto prima. Avrei dovuto dare loro un piccolo V1 con cui lavorare. Avrei anche potuto creare un forum per i primi utenti su cui iniziare a creare reti e creare una comunità fino a quando non fosse stata creata la prima versione dell'app. È stato un errore farli aspettare tutto quel tempo.
Non solo questo avrebbe mostrato più rispetto non perdendo il loro tempo , ma mi avrebbe anche fornito un feedback prezioso che avrei potuto utilizzare per iterare molto più rapidamente. Se c'era un difetto UX nella mia idea di come dovrebbe funzionare la ricerca di Artyst, l'avrei potuto imparare nel primo mese o due, invece di aspettare un anno dopo.
Avevo utenti reali, ma non fornivo loro un prodotto reale da utilizzare, quindi non avevo feedback da utilizzare per indirizzare la roadmap dell'app.
Lezione : consegnare un prodotto reale al più presto. Convinci utenti reali a darti feedback e a ripetere rapidamente.

Conclusione
In poche parole: se dovessi riavviare Artyst oggi, farei quanto segue entro il prossimo mese:

• Crea una piccola app su Adalo che supporti la creazione e la ricerca del profilo utente (la messaggistica potrebbe essere gestita sui social collegati)
• Crea una piccola pagina di destinazione con un'e-mail
• Interagisci con la community musicale su Twitter e Reddit (usando i miei account personali) indirizzandoli alla pagina di destinazione
• (e probabilmente pubblica ancora alcuni annunci IG...)
• Avviato al più presto e inizia a eseguire l'iterazione con utenti reali

Con questa strategia, avrei lanciato in 30 giorni per meno di $ 100 e da quel momento in poi continuerei a ripetere dal vivo con utenti reali.

Questa è una panoramica di 50.000 piedi di ciò che ho imparato lanciando Artyst nell'ultimo anno. Spero di averti dato alcuni pensieri utili da considerare mentre ti immergi con la tua app.

GRAZIE

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Yogi_Fastlane]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Looking back, I would’ve given more attention to non-paid social media marketing — the kind where you engage with users directly. For example, I would’ve followed Instagram and Twitter pages with high engagement among musicians (eg, XXL, Murda Beatz) and engaged with the commentors in their posts. Second, I should’ve made connections in online forums — there are several really good subreddits for different music niches that could’ve given me really valuable feedback and been a great source of early users. You can likely apply this strategy to your own niche.

Valuable relationships with users
While I built a decent audience for Artyst, my main regret is not delivering value much much sooner. I should’ve given them a small V1 to work with. I could’ve even created a forum for early users to start networking and building a community on until the first version of the app was built. It was a mistake to keep them waiting all that time.
Not only would this have shown more respect by not wasting their time, it would’ve also given me valuable feedback that I could’ve used to iterate much more quickly. If there was a UX flaw in my idea of how Artyst search should work, I could’ve learned that in the first month or two, instead of waiting a year later.
I had real users, but I didn’t give them a real product to use, so I had no feedback to use for directing the app’s roadmap.
Lesson: Deliver a real product ASAP. Get real users to give you feedback and iterate quickly.

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

This is a 50,000 foot overview of what I’ve learned launching Artyst over the past year. I hope it gave you some useful thoughts to consider as you dive in with your app.

I hope you succeeded, nicely explained !!!

 

[lizzzlizzliz]

Don't you have to make a Patent on your app/idea so that someone else wouldn't copy it?

 

[BizyDad]

Don't you have to make a Patent on your app/idea so that someone else wouldn't copy it?

It usually doesn't help. Of course you should still do it.

Someone still takes your idea, makes a couple simple changes to it, and then calls it their own idea.

Also, you need to have enough money to pay the lawyers to scare the other person, who pays their lawyers, and at the end of the day, the only winner is the lawyers.

Focus instead on having a really good product, and a really good connection to your user base. Create raving fans.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[lizzzlizzliz]

It usually doesn't help. Of course you should still do it.

Someone still takes your idea, makes a couple simple changes to it, and then calls it their own idea.

Also, you need to have enough money to pay the lawyers to scare the other person, who pays their lawyers, and at the end of the day, the only winner is the lawyers.

Focus instead on having a really good product, and a really good connection to your user base. Create raving fans.

You're right, I'll do that then!

 

[Chrisrod2597]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Looking back, I would’ve given more attention to non-paid social media marketing — the kind where you engage with users directly. For example, I would’ve followed Instagram and Twitter pages with high engagement among musicians (eg, XXL, Murda Beatz) and engaged with the commentors in their posts. Second, I should’ve made connections in online forums — there are several really good subreddits for different music niches that could’ve given me really valuable feedback and been a great source of early users. You can likely apply this strategy to your own niche.

Valuable relationships with users
While I built a decent audience for Artyst, my main regret is not delivering value much much sooner. I should’ve given them a small V1 to work with. I could’ve even created a forum for early users to start networking and building a community on until the first version of the app was built. It was a mistake to keep them waiting all that time.
Not only would this have shown more respect by not wasting their time, it would’ve also given me valuable feedback that I could’ve used to iterate much more quickly. If there was a UX flaw in my idea of how Artyst search should work, I could’ve learned that in the first month or two, instead of waiting a year later.
I had real users, but I didn’t give them a real product to use, so I had no feedback to use for directing the app’s roadmap.
Lesson: Deliver a real product ASAP. Get real users to give you feedback and iterate quickly.

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

This is a 50,000 foot overview of what I’ve learned launching Artyst over the past year. I hope it gave you some useful thoughts to consider as you dive in with your app.

Thank you for sharing. This is exactly what I needed to read today

 

[standrews00]

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

Love this, how necessary is the first bullet? I've heard and read the notion "build a community or product, not both at the same time." Your thoughts?

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[basuragone]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Looking back, I would’ve given more attention to non-paid social media marketing — the kind where you engage with users directly. For example, I would’ve followed Instagram and Twitter pages with high engagement among musicians (eg, XXL, Murda Beatz) and engaged with the commentors in their posts. Second, I should’ve made connections in online forums — there are several really good subreddits for different music niches that could’ve given me really valuable feedback and been a great source of early users. You can likely apply this strategy to your own niche.

Valuable relationships with users
While I built a decent audience for Artyst, my main regret is not delivering value much much sooner. I should’ve given them a small V1 to work with. I could’ve even created a forum for early users to start networking and building a community on until the first version of the app was built. It was a mistake to keep them waiting all that time.
Not only would this have shown more respect by not wasting their time, it would’ve also given me valuable feedback that I could’ve used to iterate much more quickly. If there was a UX flaw in my idea of how Artyst search should work, I could’ve learned that in the first month or two, instead of waiting a year later.
I had real users, but I didn’t give them a real product to use, so I had no feedback to use for directing the app’s roadmap.
Lesson: Deliver a real product ASAP. Get real users to give you feedback and iterate quickly.

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

This is a 50,000 foot overview of what I’ve learned launching Artyst over the past year. I hope it gave you some useful thoughts to consider as you dive in with your app.

Have you thought of attracting talent not with a boat of money but by appealing with their senses? Is there a way you could learn some tactics from expert storytellers and copywriters to explain the purpose of your mission, why it is needed, and larger/altruistic purpose behind your project/product? Who are you trying to benefit? Could you imagine that there are developers out there who also feel or are affected by the pain point that prompts the need of your product?

It is said that people expect to be paid a lot of money for work that they like/care about the least. You could flip the script to your advantage. I hope you would find some of this helpful.

 

[drystan45]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Looking back, I would’ve given more attention to non-paid social media marketing — the kind where you engage with users directly. For example, I would’ve followed Instagram and Twitter pages with high engagement among musicians (eg, XXL, Murda Beatz) and engaged with the commentors in their posts. Second, I should’ve made connections in online forums — there are several really good subreddits for different music niches that could’ve given me really valuable feedback and been a great source of early users. You can likely apply this strategy to your own niche.

Valuable relationships with users
While I built a decent audience for Artyst, my main regret is not delivering value much much sooner. I should’ve given them a small V1 to work with. I could’ve even created a forum for early users to start networking and building a community on until the first version of the app was built. It was a mistake to keep them waiting all that time.
Not only would this have shown more respect by not wasting their time, it would’ve also given me valuable feedback that I could’ve used to iterate much more quickly. If there was a UX flaw in my idea of how Artyst search should work, I could’ve learned that in the first month or two, instead of waiting a year later.
I had real users, but I didn’t give them a real product to use, so I had no feedback to use for directing the app’s roadmap.
Lesson: Deliver a real product ASAP. Get real users to give you feedback and iterate quickly.

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

This is a 50,000 foot overview of what I’ve learned launching Artyst over the past year. I hope it gave you some useful thoughts to consider as you dive in with your app.

Thanks for sharing this

 

[DrivedDude]

Hi all, I'm am occassional browser, rare poster here. Earlier this year I posted about a music networking app I was building called Artyst. Well it finally launched just last week, so I thought I'd check in and share what I learned.

Hopefully this will be useful to someone thinking about launching an app. Maybe you can avoid some of the mistakes I made. Happy to go into more detail if anyone's curious!

--------

This post is the story of Artyst, my just-launched music networking app. I started working on this app over a year ago, in June 2019. The app finally launched on July 1st, 2020. I’ve spent a ton and learned a ton over that timeline. But I also made a ton of mistakes.
I’m confident I could get this project launched for a fraction of the cost in a fraction of the time if I was starting again from day 1, knowing what I know now. Here are a few lessons I learned.

Start lean… and stay lean
Like many tech founders, I’ve read The Lean Startup and made an effort to apply lean thinking to my work on Artyst. I spent the first few months sketching UIs, paying for app screen mockups on Fiverr, creating personas, launching a small landing page. I got feedback on these from musicians I know as well as by running Facebook + Instagram ads. This provided sufficient validation that the idea was worth pursuing. I believe this process was worthwhile, though I went a little too far worrying about details and revisions — it shouldn’t have taken more than a few weeks.
Unfortunately, staying lean was much harder. I’d defined a truly minimal version of the app to build. But after a few iterations with the developers, the final specs came out as an extremely bloated version of the MVP. I went from “create and search profiles” to “profiles, chat, news feed, featured section, and more with full iOS + Android support from day one”. A huge undertaking that dragged on several months longer than planned, resulting in several disappointing delays for my users. If I had stuck with the minimal version, I would’ve launched much earlier for less money and ultimately created a better relationship with my users.
Lesson: Start lean. But be careful also to stay lean. Watch out for scope creep. Keep your “minimum viable product” to the true minimum.

Build it yourself

Issues with paying for development
Working with developers has been the biggest cost in launching Artyst — in terms of both time, money, and stress.
I’m a career data scientist. I know how to code. But I’ve never done app development, so I went into this project with the mindset of “leave it to the pros” and decided to pay for a developer.
Initially, I went with a cheap developer from Fiverr for a few grand. He did some decent work, but after several crap deliveries and deadline overruns, I decided to move on. I’d wasted a lot of time, money, and stress.
Next, I decided to go with a “real” app development group. After getting several quotes in the $100k range, I finally settled on a “modestly priced” group for $25k. Yikes. But worth it, I thought, because these guys are gonna hit the deadlines and deliver a super professional app. That’s a ton of money, and I spent a lot of time talking to them before making the decision. How could they not?
… wrong yet again. Development went months beyond the expected launch date. Specs were ignored. I had to fight to get clear answers. A lot more time, money, and stress.
Maybe you are better at vetting developers than me. I don’t doubt you. Just be careful. Don’t assume price = quality. And don’t take anyone’s word for anything. Understand your leverage in each situation, understand the other party’s incentives, and always have a backup plan.

Benefits of building yourself
The alternative? What should I have done instead? Build it myself. If you know how to code, great — do that. But if not, you now have a ton of no-code options available. Sites like Bubble and Adalo that let you build web and mobile apps in a drag-and-drop manner.
I really regret not using tools like these from day one. I had concerns like, but then won’t my app be slow and clunky? Won’t the design be sub-optimal? Maybe a bit. But don’t assume it won’t be just because you pay for a developer. Won’t it limit what my app can do? Maybe… but increasingly, not at all. And even if my desired app function doesn’t exist with no-code, there’s likely a good enough substitute to make it worth using no-code for an MVP — you can always transition to code later after a successful V1.
Put simply, the benefits of building yourself (with or without code) are cost and control.
If you’ve got a stack of cash you’re willing to throw toward a moonshot app development, go for it. But most people don’t. I barely made it work. Coding yourself is typically free until you need hosting — and maybe still free then until you scale up. If you’re going the no-code route, most of these sites offer a free plan or at least a generous trial period. After that, you’ll pay per month, a couple hundred dollars on the higher tiers. Either way, much cheaper than paying for a full development.
And then control comes into play. If you’re relying on developers, you’re not in charge of the timeline. You can set deadlines, sure, but what are your options if they’re not met? And most importantly —the part I regret the most — what do you do after the initial build? If you want a bug fixed, a new feature added, a tiny UI tweak, do you want to have to pay thousands more and wait another month or three on your developer? Or can you tweak the app yourself same-day or, worst-case, over a long weekend?
Lesson: Built it yourself quickly and cheaply.

Get real users, provide real value, get real feedback
A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

Acquiring users
Next to development costs, user acquisition has been my second largest expense. I’ve spent several thousand dollars running Facebook and Instagram ads to get page follows and email signups on the Artyst website. I can’t say I regret this — in the case of Artyst, social media ads have actually worked really well for gaining exposure. But this is by no means the only way to do it.
Most people won’t have the budget to drop this kind of money on ads, which is understandable. And even for those who do, it doesn’t always work well. This depends on where your target users hang out and how easy they are to nail down using Facebook’s ad audience parameters.
Looking back, I would’ve given more attention to non-paid social media marketing — the kind where you engage with users directly. For example, I would’ve followed Instagram and Twitter pages with high engagement among musicians (eg, XXL, Murda Beatz) and engaged with the commentors in their posts. Second, I should’ve made connections in online forums — there are several really good subreddits for different music niches that could’ve given me really valuable feedback and been a great source of early users. You can likely apply this strategy to your own niche.

Valuable relationships with users
While I built a decent audience for Artyst, my main regret is not delivering value much much sooner. I should’ve given them a small V1 to work with. I could’ve even created a forum for early users to start networking and building a community on until the first version of the app was built. It was a mistake to keep them waiting all that time.
Not only would this have shown more respect by not wasting their time, it would’ve also given me valuable feedback that I could’ve used to iterate much more quickly. If there was a UX flaw in my idea of how Artyst search should work, I could’ve learned that in the first month or two, instead of waiting a year later.
I had real users, but I didn’t give them a real product to use, so I had no feedback to use for directing the app’s roadmap.
Lesson: Deliver a real product ASAP. Get real users to give you feedback and iterate quickly.

Conclusion
In a nutshell: if I was re-starting Artyst today, I would do the following within the next month:

• Make a small app on Adalo that supports user profile creation and search (messaging could be handled on linked socials)
• Make a tiny landing page with an email grab
• Engage with the music community on Twitter and Reddit (using my personal accounts) directing them to the landing page
• (and probably still run some IG ads…)
• Launched ASAP and begin iterating with real users

With this strategy, I’d launch in 30 days for less than $100 and be iterating live with real users from then on out.

This is a 50,000 foot overview of what I’ve learned launching Artyst over the past year. I hope it gave you some useful thoughts to consider as you dive in with your app.

Thanks for your post. As a developer I agree, it’s damn hard to keep the first MVP lean. I wasted two weeks for the landing page. You are a great reminder to overthink my system.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[mooney14]

A consequence of all this feet-dragging on the Artyst release timeline is that I’ve had thousands of aspiring users waiting on this app for months. That’s a mistake. I should have given them something real to engage with from day one (or, at they very least, month one).

It sounds like you got all the "aspiring" users from ads? I'm working on developing a gym management platform and was going to use surveys at local gyms to gather market intel in order to determine interest level. It sounds like you went the route of paid ads? Was this to reach a larger audience?