Hi redditdev community,

I registered a new app at https://ssl.reddit.com/prefs/apps/ but with no response yet. Since it's been a few days now I was wondering how long approvals actually take?

Hello folks!

I'm thinking about building an app for my personal use and perhaps even share with a larger user-base, if it's come out decent and presentable. There are tons of tutorials online, but I'm having a hard time deciding which one to follow. I would also need some guidance on the IDE to use to start designing the UI/GUI and how to do the backend programming.

I have decent programming skills (SQL, SAS), though perhaps not in languages that might be relevant for this job - please feel free to correct me if I'm wrong.

Couple of caveats:

• This app will be an Android app to start, but eventually I might want to have a web/desktop version as well.

• I am somewhat familiar with web programming languages such as HTML, CSS and Javascript. Not sure if that helps, but I wanted to provide this information.

For context, I am a Data Analyst working remotely and have a lot of free time on my hands after work, which I would like to start using productively. Which brings me to my final question. Realistically, I can dedicate between 10-15 hours a week to this and with that, how long would it take me to build a moderately complex app?

Thank you in advance for your help!

What are the about url and redirect uri fields? i looked up a video on using praw and he just put pythonprogramming.net for both, but i feel like knowing specifically what they do will be important in the future

Over the past two years, my boss (my wife) finally gave me permission to chase my crazy ideas and build a couple apps for business ideas I had. While I’ve played around with WordPress some before, I have no real technical background when it comes to coding, developing, etc.

The harsh reality is this. I wasted A LOT of time and A LOT of money because of things I had to learn the hard way. I’m hoping by sharing some of those things here, it can help some of you who have dreams that require dev (that’s what the cool kids call development), but you don’t have the technical background.

Here are nine things I think might be helpful to know/do.

1.  Start with one platform (iOS or Android).

It can be tempting to see your dream app launched on every platform out there on day 1, but there are a lot of complications that come with that. With one of our first apps, we tried to build iOS, Android, and web app (desktop) at the same time. Here’s what I didn’t see coming with that:

• It’s WAY more than just 3x more expensive. - Not only do you have to hire an iOS dev, an Android dev, a frontend web dev, and a backend dev, but you are going to have 3x as much testing to do, extra developer accounts to set up and pay for, challenges that arise when certain features don’t act the same on different platforms, additional Slack/email/etc. accounts to set up and pay for, additional design work needed for each platform, and probably a lot more I’m not thinking of right now…It is WAY more expensive than you might think, primarily for the next reason.

• Different devs work at different speeds, which means risk for wasted time. - Ever drive by a construction site and see people just sitting around because they’re waiting on someone else to finish up? The same thing is going to happen if you’re doing multiple platforms. It’s allegedly doable, but you have to sync up making sure the designs and everything are done in time, making sure the backend (which all three environments talk to) knows what’s going on, making sure features are properly discussed with everyone, etc… We tried it, and failed miserably.    

With our most recent app, we just did iOS to start and it was a wildly better experience. We hired a backend developer, an iOS developer, and a QA tester (quality assurance-I’ll cover necessary and wasteful roles in a second). Managing the project was way easier, it was far less expensive, and we got finished way quicker.

And if you’re worried about missing out on customers from the other app store, here’s a suggestion that we did. To ensure we don’t lose too many people who hear about us and have Android, we included an email capture for them to get notified when we release on there. That way, when we launch, we can send them an email and get those sign ups.

Final thought: There are things like Ionic and NET Maui that allow you to manage multiple platforms at once, but I have no experience with them so I can’t recommend to advise against. Just sharing. If you do choose something like this, I would recommend getting a VERY clear picture of the limitations for current features and future features you want, if any.

2. Hiring is a nightmare.

Full transparency, I won’t have the best solution for you here, but I do have a hefty list of mistakes to avoid that should be helpful.

Finding good devs is a nightmare. When I first started, I had no idea where to look, who was qualified, what I needed, or anything like that. EVERYONE tells you they’re the best in the world, and most of them are full of it.

Here’s a list of mistakes I made and maybe a few glimmers of hope.

Avoid the big box places where one person does the hiring for you.

I won’t mention the company but I met with a large talent company who said they had the top something % of devs in the world. They claimed to vet them and test them extensively. I knew they’d be a little more expensive, but the experience was beyond terrible.

First, they jack up the rates of what devs should cost sometimes by 50%+. I knew there would be a markup, but I didn't realize it would be this extreme. I tried to do some research into rates beforehand, but they pulled the wool over my eyes and told me I was getting the best and that these were what rates were, so I figured it would save me in the long run (wrong). I will share some rate guidelines in a few based on my experience to give you a jumping off point.

Second, they bloat the team by a million miles. They had me hire like 9 people, which I was stupid enough to agree to. Scrum masters, designers, devs of all shapes and sizes…they told me I needed every single one of them, and I believed them (wrong).

Third, they had us do a several week “idea exploration” process to fully get the idea specifications broken out. Sounded like a good idea, but in the end, it was nothing more than a bunch of people sitting around talking and pitching ideas. I’ll talk later about how this process is important, but you don’t need 9 people full time for 2-3 weeks to accomplish it.   

Fourth, not all the devs were very good. I literally had a dev taking personal calls during our meetings and who worked maybe a few hours and tried to charge us for a full 40 each week. The company did give us a partial refund on it, but I had to fight for it.

Worst experience of my life.

You HAVE to find a dev you can trust to help with hiring.

In the end with the first app, we cut ties with that big company and I had to pay a buyout to get the one dev from the process I trusted. That said, he was integral in helping things move forward. As we started to hire from places like Upwork and similar platforms, he was able to conduct interviews and ask really detailed technical questions to see how applicants thought about problems and if they genuinely had experience.

It still wasn’t full proof, though. For one, he didn’t have experience in every coding language, so he could only look at candidates processes instead of exact technical questions. Also, it’s just hard to get a feel for someone’s skill on an interview for something like this.

In light of that, here are some tips I would suggest.

• Again, find a dev you can trust. Look for someone from referrals, high ratings, etc. The better you get this, the better the rest will go. I wish I had better suggestions here, but I don’t. (I am willing to make an introduction to a few of the good devs we’ve had along the way, but please don’t waste their time.)

• When your trusted dev interviews candidates, have them ask hard questions. Have them ask for a link to their GitHub. Have them ask for references. Have them ask for prior projects. Have them ask to see code samples. One note here—if/when they give you code samples, see where they're from. If they're from a past project of another client, be on guard. This is a red flag of how they might treat your code in the future because that might not be theirs to share.

• Remember the bill is always paid by you. Be part of these interviews. If something feels wrong, don’t overlook it just because you’re excited (I did this and paid for it).

• The second you realize someone is dead weight, cut them lose. We held on to people far too long that needed to go way sooner, and that cost us a lot of wasted cash.

• Make sure the person you are interviewing is the one working on the project. We’ve seen people try and pull the switcheroo to include someone passing answers to someone during an interview lol. Also, make sure you’re not talking to a project lead who is just going to outsource the work to junior developers. Ask them point blank if they are doing 100% of the work.

• Don’t forget to factor in working hours and time zones when hiring. If you have people all over the world in different time zones, it does slow things down. The more overlap you can have, the better.

• We had disproportionately bad success with people named Connor, so maybe avoid hiring anyone named Connor. I’m kidding, but I’m also not.

Here are the roles that I think are critical, might be needed (based on your skills), and the ones that are worthless.

These are just my opinions and projects come in all shapes and sizes, so take what you want and leave the rest here.

• Backend Dev - definitely necessary. Most apps (from my understanding) have all the “logic” and thinking parts on a server and the apps just call from that server and show it on the phone.

• iOS/Android Dev - definitely necessary. You need someone who knows the platform you are building on.

• Designer - maybe necessary. This was maybe our biggest waste of money, though. I am embarrassed to say how much we paid for a designer who in the end just gave us a “style sheet” I probably could have come up with in a few hours myself. Yes, there is value in hiring a professional here, but make sure you know EXACTLY what the deliverables will be and do payment on a per project basis, not hourly.

• QA Tester - most likely needed. This is a person who tests the app for bugs and mistakes. I thought I could do this myself and realized that even though I am extremely detail oriented, I still was not the best at it. Having a good tester really did a lot for the value of our project. (I do have a good tester who is only part time for us right now, so reach out if you’re looking for someone but again, please don’t waste his time.) Also, be aware there are two types of testers. One who is a skilled dev and uses scripts to test the limits of things. The other is someone who is less expensive, but is just super detail oriented to clicking through and finding ways to break what was built. We saved by hiring the latter and letting our devs handle the first as they had some experience in it.

• Scrum Master - waste of time unless you’re not involved in the project. This is like a project manager who uses a system called Scrum to manage the team. Honestly, I found Scrum to be a waste of time with way too many meetings and it had a weird hatred for deadlines, which I wasn’t a fan of at all. I actually went and took the scrum master class and test during out project to take on the role myself (and prove a point, but that's another story for another day). In reality, I even further found scrum to be a waste of time, but I know a lot of people will disagree with me. THAT SAID, if you do not have project management experience of some type (I have a lot from past businesses and being a military officer), you should hire someone to manage the project. Additionally, I was available 24/7 due to my work at the time, so that helped a lot.

• DevOps - So, DevOps is the process that big companies use to push new “builds” (think versions) through “pipelines” to the testing team and then to “production” (what the real user sees). Think of this like moving a dish from your oven (development environment), to the kitchen counter (test environment), to the dining table for your guests (production environment). I have mixed feelings on this one. It 100% makes sense to protect against problems when you’re pushing updates when you have real users, but it’s also kind of a luxury in my mind. It’s super expensive to find someone good, and while I think it has helped us a lot—I still think I’d avoid it in the future until we got bigger. When you’re just doing an app, you can use things like TestFlight as your test environment (provided by Apple). Also, if you’re just having your app built and trying to save, I might look to skip DevOps and build it out later once you’ve seen some success.

To give you a starting point on what these people may cost, here are the rough rate ideas I’ve seen from our experience.

These are really rough and just ranges based on what I saw with people we hired and didn’t hire.

Developers (all types)

• India/Middle East - $10 - $40 an hour

• Eastern Europe - $25 - $70 an hour

• Europe - $40 - $150 an hour

• U.S. - $50 - $150 an hour

A few additional notes here:

• Higher rate does NOT always mean more skilled.

• Lower rates DO generally mean less skilled, minus a really random outlier here and there.

• You can find hidden gems overseas, especially in some areas of Eastern Europe. I did find that area to be the best mix of skill and value.

• I found that everyone in the U.S. charges U.S. prices, regardless of their actual skill. In other words, the biggest discrepancies between skill and rate were in the U.S. (this doesn't mean there weren't devs in the U.S. that deserved these rates)

DevOps

• $100 - $300 an hour (could only find in the U.S. and Europe)

Scrum Masters and QA Testers

These were ALL over the place but were generally less expensive than the devs.

3. Turnover is expensive.

When you find great devs, treat them like kings and queens. When you have to bring someone new on, expect that process to take about a week, sometimes a little longer to really ramp up to speed. During this week, your lead dev (usually your most expensive) has to take their time to train up the new dev on the project. So, you’re paying for both of their time, while nothing new is being developed. Also, if you're doing multiple platforms (and sometimes even with one), this can mess up your synchronization and you end up with that construction site problem of people sitting around.

That said, don’t let this be a reason to hang on to someone who is deadweight, because that is WAY more expensive.

4. Get contracts in place for EVERYTHING.

This is a basic business rule, but a must with development. Make sure you have NDAs, non-competes for your industry, and proper contractor agreements that cover things like (this is not an exhaustive list):

• Rate of pay

• Services to be performed

• Ownership of materials

• Proprietary information

• Independent contractor status (not a partner, no taxes withheld, no insurance, etc.)

• Termination of the agreement

• Confidentiality

• Revolving disputes

• Applicable law

Again, I am not a lawyer, so these are just suggestions. Do not take any of this as legal advice. Get a real lawyer and not just the Offices of Chat GPT, Attorney at Law.

4. Research the technologies you might use first.

Just because you don’t have a technical background does not mean you shouldn’t try your best to know as much as possible. Here are a few realities:

Devs tend to pick what they like. This can be a good thing, but they might like something because it’s rare or complex. Or, it might be something new that they are learning and are excited about.

The reality is that you are not their playground. Additionally, finding replacement devs for a complex or weird coding language can be hard.

You are generally stuck with what the first dev picks. If your first dev proves to be a dud and they picked an awful language/framework, you are left with the hard choice of deleting everything or a tough hiring process.

Now, all of this is tough when you have no technical background, but here are a few tips.

• When they suggest a language/framework, look around at places like Upwork to see how many people there are saying that is their specialty. If you find none or very few (or it’s always an afterthought in their profiles), that’s probably an issue.

• Ask them to tell you WHY they chose that framework.

• Ask them to give you time to do some research on your own.

• Pay for an hour or two of another developer’s time for a consultation to get their opinion on the framework set up. Devs love to crap on other devs for some reason, so use this to really battle-test the set up.

One real world example of this is that we chose to use Microsoft Azure over AWS for our servers. In the end, I think this ended up being the right choice for us, but finding AWS devs is WAY easier than finding Azure devs, especially with the DevOps stuff. I do think more devs are trained in Azure now so it’s not as big of a deal, but just an example from when we started to give you an idea of what I mean.

5. Control the log ins.

I’m going to put this in all caps because it’s that important. MAKE SURE YOU CAN ACCESS EVERYTHING AND THAT YOU CONTROL THE LOG INS TO EVERYTHING. Your devs should never have access to something that you can’t shut them out of in an instant.

Thankfully, our first dev was super smart on this and had every person we hired get a lovetrackapp email and use that for anything and everything. That way, if you ever have to let someone go, you don’t have to worry about them having access to things that you don’t.

In practice this means, you set up the Gmail admin account, you control the domain name, you control the main access to the servers, you control the Apple Dev account, etc. You can ALWAYS add people as devs with proper permissions, but you need to be the super admin across the board. This may take a little learning on your part, but it’s doable. For clarity, this doesn’t mean you just have a log in, but it means you are the super admin who literally clicked the “sign up” or “create account” button.

Ideally, this is never important to you, but if it ever is, you’ll be happy you did it.

6. Understand what an MVP is and be okay with it.

MVP stands for Minimum Viable Product. In other words, it’s the smallest/lightest version of your app that you can build that is good enough to at least test and see if the idea is good or not.

As someone without a tech background and a lot of passion for our project, my idea of an MVP was WILDLY different from what a real MVP was—and that cost us money. The idea of an MVP is to get to market and be able to start getting users and seeing if you have a winner without breaking the bank. The problem, though, is I struggled to separate what would be a super helpful feature and what was essential.

With our first app, I blew this…hard. I thought everything was a must have when it really was not. With out most recent app (LoveTrack, a date night planner), I finally got this right. To frame the example, here’s a quick description of what the app does. The app helps you plan better date nights by showing real events in your area on the day you want to have a date night, by showing you custom/unique dates, and by walking you through how to plan these dates/what you need/etc.

The only things that are essential are getting people’s basic information about what they want, showing them date ideas, and allowing them to walk through the process to plan the date. Everything else is nice and will be added later, but is not part of the MVP.

The more cutthroat you can be with what you exclude from your MVP, the more you’ll save. Once you know you have a winner, go wild with the features.

There’s a small caveat to this that I’ll cover in the next section.

7. Save money by having the most obnoxiously detailed specs ever BEFORE you talk to anyone.

The single best way to save time and money with your app build is to have obnoxiously detailed specs about every feature, every screen, every functionality—everything. A LOT of the time spent with our projects that could have been saved was fleshing out functions and thinking through all different scenarios.

What I’ve learned is that with the right mindset, you can do this yourself. Doing it with the whole team is fine, but you are paying for everyone’s time in that meeting. For example, if you have 5 devs and they call cost $50 an hour (oversimplifying as a hypothetical example here), that's $250 an hour for planning. If you only have things fleshed out to 50%, that’s a lot of overhead to get to 100%. But if you come in at 95%, it won’t take long to get the team moving on actual development.

Here’s an example of the mindset. With LoveTrack, I wanted the live events happening on the day of your date (things like concerts, plays, festivals, etc.) to show at the top of the screen after you answered some questions about your date.

When I first started (with our other apps), that’s the extent of how I would have described the feature. However, here’s what I would include with it now:

Feature: Show live events from Ticketmaster partnership at the top of main dashboard page

• Show up to X number of events.

• If fewer than X number of events exist, show Y.

• If no events exist, show Z.

• If fetching of events fails, show XY.

• If app goes offline, show XY.

• Show events in a carousel. Here are a few links to samples and screenshots that look like what I want.

• Carousel should take up roughly 1/3 of screen on most devices.

• Sort events this way.

• Here’s a sketch of the information I’d like shown for each event and how I’d like it laid out.

• If event name is too long to fit, do this.

• Navigate here if link is clicked.

• Button text should be X.

• Here’s a link to the Ticketmaster API information.

Just an example and not with the exact details, but the idea is to show you how to think of EVERYTHING. Even the simplest of buttons should be broken down this way.

If you have different membership levels, have a levels matrix where you clearly show what permissions each level of member has. The more obnoxiously detailed you can be, the better.

Marking MVP vs Future Feature

One thing that’s super important is marking which features are for MVP and which are future features. You might be asking, “Wouldn’t it confuse them to put all of this into the same document? Shouldn’t I just show them the MVP features only?”

While I get the logic here, the reality is there are ways they can build things that make way for future features down the line. So, having your devs aware of your definite future features and your “hopes and dreams” features, can really be helpful in how they build things to save you time and money down the line. A good dev will be able to give you options along the way like “we could do it this way that would work now but will make this harder later or we could do it this way now which would take X number of additional days/hours, but will make that way easier later”, and then you get to decide.

What You Think is Hard Might Not Be. Vice Versa

Something I tried to do was manage the features the devs worked on based on how long I thought it would take. I would neglect telling them about certain features because I figured it would take too long and I wanted to keep them focused to manage the budget. The problem with this is that some features I thought would take days literally took like an hour and were HUGE improvements. This was also true the other way around.

The takeaway here is to get time estimations on all the ideas you have (one thing I did like from the scrum process). I thought I knew what was easy and what was hard, and I was wrong…a lot.

8. Have a technical plan for scaling.

Quick story time—I have a friend who built an app that started off pretty successfully. They got up to 100k users, and everything was going great—until the app crashed because it wasn’t built to handle that level of volume.

If you’re expecting a ton of users, make sure you hire devs that understand scaling. The term I heard tossed around by people who seemed to know what they were talking about was “enterprise level”. Basically, these skilled devs could easily articulate to me how things would work and what would change (automatically and manually) as we got to certain user levels, with specifics.

Now, is all of this necessary from day one? Probably not. I’d say that we overspent on doing these things when we were just trying to validate an idea, but it’s not like they’re wasted costs down the line if you succeed.

And remember, every dev will tell you that they know how to scale. Find someone who has experience with it or can talk you through it without just hitting you with tech jargon. Again, I don't have a great answer for sifting through the mud here, but do your best.

9. Stay on your people. Daily.

Lastly, and this is an important one—trust but verify. Stay on your people daily. Get daily status reports from people. Don’t let things go for a few days or even a week. If you are not 100% transparently clear on what is going on, you’re doing it wrong. If you are ever surprised by a delay, you’re doing it wrong.

I trusted that everything was going great far too often. This cost us time, money, and quite a bit of sanity. Even a few days gets expensive with dev and can get everyone off track. There were always ripple effects that seemed to last for a while when one person was off track.

And there is a nuance here that is important. With the first apps, I did this, but I didn’t press when I didn’t understand something. I didn’t pry when I thought I was being fed a line. If they told me “worked on X feature today”, I took that as sufficient (it’s not). If you are not 100% confident in things, keep asking until you are. Be okay feeling embarrassed. I learned that the phrase “pardon my ignorance” would go a long way (but don’t use that if you think your devs will use it as a way out).

Remember, they work for you. You are paying the bill, so you deserve to understand where things are. This also makes it WAY easier to drill down on what went wrong when a deadline is missed.

Edit*: Just wanted to clarify something here based on a few comments. I am NOT advocating for micromanagement at all. All I'm saying is make sure you're aware of what is going on, what's being worked on, and what the status of things are.*

Thanks for reading

Anyways, I hope this helps. If you want to check out our most recent app, it’s called LoveTrack. I think it’s super cool and was the first chance I got to put the lessons I learned in the past to work. If you want to support us, check it out and tell a friend!

I’ll be around to answer any questions anyone might have.

I'm not a developer. I'm part of a large and growing niche community, though, that has been using existing apps that are "good enough" but don't quite fit our specific needs. I have ideas that I think would make for a successful app, but I have no idea where to start with the development part.

Who do I go to? Development companies? Freelancers? I've got the ideas, contacts, and access to funds. What now?

After click "create app" just receive this message

"In order to create an application or use our API you can read our full policies here: https://support.reddithelp.com/hc/en-us/articles/42728983564564-Responsible-Builder-Policy"

But nothing actually created and no keys

Hopefully this isn't too basic of a question!

I'm looking to write a few apps that will use the reddit API. I intend for these to be purely personal use--python scripts running on my personal machine. They won't do much more than pull from the /new/ feed of a few subreddits from the perspective of the API. Simple enough, but here's where I'm confused:

• The API access guidelines say that I must register my app via the included Google form to access the API.

• The page to actually create an app says that I must register my app "for production API use," which is not defined.

• The handful of tutorials that I've looked up do not mention the registration form at all. Ex: this one just creates an app and immediately goes onto making API calls.

I looked through the registration Google doc, and the terms look like they're geared towards larger apps, but the form itself includes instructions for individual-use apps. So which is it? Do I need to register these small script-type apps through the aforementioned Google form?