,

Why we (generally) don’t recommend React Native (or other cross-platform solutions) anymore

TLDR: frequent interminable library conflicts, deep knowledge of native platforms required to debug issues, and devastating edge cases result in no real difference it total cost of development with a huge increase in complexity.

In 2015, Facebook’s cross platform framework (meaning it could run on both iOS and Android), React Native, burst onto the scene and took the mobile world by storm. In the next couple years, big companies like Airbnb, Soundcloud, and Discord hopped on board, as well as more niche but influential companies like Artsy. People everywhere were drawn to the many potential advantages: shared cross platform code, the availability of developers, development speed, and the promised performance parity with native code.

By 2018, however, some of those big companies had begun abandoning React Native, Airbnb being the most visible of them, writing a large, multi part post-mortem on React Native at Airbnb. That year was also the peak of the search term, which has been declining since then:

LithoByte also experimented with React Native, and developed our in house expertise to the extent that we even accepted clients for the platform. However, we quickly abandoned the platform; let’s look at the reasons why. First, though, a brief history of mobile cross platform frameworks.

The History of Cross Platform Solutions

We at LithoByte have always been suspicious of cross platform solutions since the first few came out. In 2012, Mark Zuckerberg famously said that betting on HTML5 for cross platform capabilities was the biggest mistake Facebook had thereto made as a company. The problem was many-fold, but not least was that performance was poor compared to native development.

Xamarin was and is another cross platform solution, but never got the sort of attention that either HTML5 or React Native did – perhaps because it uses a less known programming language, is made by Microsoft, or some other reason entirely.

Fundamentally, though, what all cross platform solutions share is that they will, by definition, always be at least one step behind native, in a couple respects. First, there’s always some extra layer that translates the cross platform code into single platform code – this will always cause some sort of performance hit; you can minimize it, you can try to work around it, you can design your app to make it look inconspicuous, but it will always be there. Second, when native platforms update, people who use a cross-platform solution can’t use those features immediately – they have to wait for the solution’s maintainers to incorporate the new features into the solution, or they have to write their own incorporation code, which they’ll eventually replace with the official incorporation (which means extra effort with little pay off).

This is the largest thing a cross platform solution has to overcome to be, in our opinion, worth considering for general application development. The hype around React Native indicated that, because it uses native components in the UI, it didn’t have the same sort of performance hit as other frameworks, and because Facebook was creating it, there would be little or no slow down as the native platforms updated, which led us to give it a try in spite of our reservations. Unfortunately, neither of these have proven the case.

Our experiences with React Native

1. The 80-20 effect

With React Native and many other cross platform solutions, a developer can very quickly build about 80% of their app using the cross platform framework. This experience is revelatory for many, because making so much progress so fast is a level of productivity that we rarely experience. “Gee,” we think, “if I got this much done so fast, surely the last 20% will be just as fast – I just have to fix these small bugs here or there and I’ll have a whole app done in a very short period of time!” This experience often is what developers will base their recommendations on – 80% is a long way, and the experience is so convincing, that they’ll recommend a switch based on that alone.

Unfortunately, that last 20% is a nightmarish slog. Fixing one bug causes another. Upgrading a package to include a bug fix causes a conflict with another package. Making it look nice on one platform breaks the UI on the other. You start having to write more and more platform specific code to fix these issues, along with ugly code to accommodate strange work arounds. The time saved by the first 80% is often dwarfed by the time lost to the last 20%, making the investment of dubious value.

2. More native experience necessary than native development

Our developers report that because of the obscure and arcane bugs they ran into with React Native, they counterintuitively used more of their native knowledge than if they were just developing a native app. Crashes output messages that were opaque in the extreme, requiring a deep, expert level knowledge of the native stack (on both platforms!) to diagnose, with subsequent sifting through libraries touching that part of the native stack to hunt down the cause.

This meant that LithoByte could not hire junior developers to work on React Native projects, and instead had to rely on our most experienced programmers, driving up costs for our clients in both the short and long term.

Also as a result of this, we did not receive any benefits from the shared architectural style with the web framework React – simply knowing React was not enough to meaningfully contribute to a React Native codebase because of the deep native knowledge base required to debug. As noted in Airbnb’s posts about it, rather than reducing the number of platforms from two to one, React Native increased the number of platforms to three.

3. Ecosystem volatility

As an app progresses, both business and technical considerations drive the addition of new features. To provide those new features, new libraries are often required. Unfortunately, libraries vary vastly in many respects, including: maintenance consistency, dependencies, version requirements, stability, and more. Because of this, every time a new library is added, it may have a non-trivial impact on other libraries, as you may need to upgrade, downgrade, or replace existing libraries (and the code that uses them) to support all necessary features.

This makes adding new features harder and harder as time goes on, and is part of what causes the 80-20 effect described above.

One interesting story from Airbnb relates to a bug wherein, for some devices, React Native would render the app as all white – meaning you couldn’t see anything, since everything was the same color. The inexplicable solution to this was to turn off a library included by default in React Native called Fresco. To this day, Airbnb developers don’t know why that fixed the issue. Think about that: Airbnb has some of the best engineers in the world, competing for talent and hiring from companies like Apple, Google, and the creators of React Native, Facebook. If they couldn’t figure it out, most other companies couldn’t either – let alone a startup just trying to save money.

Conclusion

We find that generally companies looking to save money are better served by concentrating on one native platform before building out a second later rather than relying on React Native or any other cross platform solution.

That said, there are times a cross platform app makes sense: cases when you are building a very standard application that doesn’t need off the beaten path features, a small scale app that doesn’t need to be high quality, and cases when you rapidly need to build out a first version that you don’t plan on maintaining long term.

For some startups we mentor, a cross platform framework can be a great way to get a proof of concept out the door – however, they will most likely, at some point, need to re-write it natively. That costs more in the long run, but if a proof of concept is needed to raise money at all, then a cross platform framework may help you get there.

/by
,

Mobile App Startups: Marketing

There are a lot of choices when it comes to marketing your app.

The first and most obvious is the old gold standard: with word of mouth. This can be achieved in a few ways: obviously, you can make a product so good that users just have to tell others about it (this is very rare, especially for a brand new app). If your app is a communication service, to an extent word of mouth is built in: if your users need other people to have it in order to communicate with them, they’re more likely to spread the word for you. You can also build a social aspect to the application (and according to the excellent Gamefication by Design, you probably should be anyway), which, if natural, will allow your users to invite others or just generally give social proof to others that they’re using your app. Finally, you can attempt to build buzz with a beta, only offering a select number of invites to give the impression of exclusivity.

After the tried and true word-of-mouth, one of our favorites is by building something people are already searching the App Store for. This reduces your marketing strategy to one of App Store Optimization, with a side of App Store Ads, if necessary. (Note: App Store Ads are not always worth it – you’ll need to review your average revenue per user to determine if the cost of acquisition through ads makes sense.)

You can also try social media awareness and advertising. This involves creating social media accounts for your app on Facebook, Twitter, and the like, and posting, inviting people to like, joining groups, and generally interacting with potential users. This can be extremely effective, especially if you’re offering something that saves you customers time or money – however, it can also be an extremely intensive process, which can easily soak up a large amount of time, energy, and money.

Another option is search engine optimization and ads. Sometimes people aren’t searching the App Store for your solution, but instead they’re searching the web. If your website comes up at the top of those search results, you could get new users that way. If you’re publishing your app on Android, you can create a campaign with Google that can automatically detect where to place ads for you, either on the store itself or in web search results. On iOS, however, you’ll need to do your own research and place ads with Google accordingly.

You might also try affiliate advertising. With this strategy, you connect with influencers or folks whose audience you’d like to reach and offer their users a discount that also gives money to the influencer – this creates an incentive for the influencer to talk about your product, and the users that come to the app through that person/organization get a nice discount while allowing them to support the influencer/creator monetarily when they may not have been otherwise. Because you’re getting paying customers, it a makes up for the money you’re paying the spokesperson, but if none of their audience uses the affiliate link/code, neither of you will make any money from it, so choosing your desired audience carefully is key.

You could also try for paid or earned news coverage – though, as a startup, earned coverage can be hard to get if you don’t already have connections to a reporter or news organization. Similar to affiliate marketing, this may or may not be effective, depending on if your potential users read the news organization your company is featured in. Most news sites, stations, and papers will allow you to pay to be featured as well – but again, choose wisely if you want to see a return on investment.

Marketing is an art and a science, and should not be taken lightly. Excellent apps have been made or broken based on their marketing strategy, and we highly recommend thinking long and hard about how you want to approach it – including speaking to experts on the subject.

/by

Algora: Student Programmers and Startups – a Match Made in Heaven

We’ve written before about how startups can attract technical talent, even when competing against tech giants like Apple, Google, and the like. One of the difficult things when thinking about that issue is how to deal with the money problem: as a startup, you don’t have any, while tech giants have literal billions of dollars to spend on developers.

There are a few ways startups attempt to solve this problem: since finding the right person at the right price takes time, they often fill the gap with contractors. And there again, you have a problem: contractors cost money, while good contractors cost lots of money (although, as the saying goes, “if you think experts are expensive, wait til you hire an amateur”). What’s a start up to do?

One option is to go offshore; however, there are many risks to this.

First, language barriers can really make things hard – even between native speakers, expressing your vision for your product is supremely difficult; how much more so when you’re talking to someone new to your language?

Second, many offshore companies are competing on price – but their currency is not actually so weak compared to the dollar that the economics make sense. As a result, many offshore companies put their employees on multiple projects at once. I don’t care how talented a developer you are, if you’re working on 5 different projects pulling 16 hour days, your code is going to suffer. And once the code starts to suffer, each new feature takes longer and longer, needs to be redone over and over, and pretty soon it costs as much as if you’d done it onshore (but with more headaches).

Third, timezones alone can wreak havoc with your timeline. When your working hours are completely disjoint, emails that take 5 minutes to answer take 12 hours to get to them, simply because they asked a question while you were asleep and you answered when they were asleep. This means you can go back and forth for days on a very simple issue, eating up valuable time in your launch schedule.

Best in class, onshore developers, though, can be risky if you haven’t yet achieved market fit. Sure, they’re fast, and high quality, but if you accidentally asked them to build the wrong product, you’re out a lot of money. This is always a danger, but when development goes quickly, it can keep you from realizing your mistake until too late.

The best thing you can do is get a technical co-founder who’s signing on for equity – but lots of folks go about getting a CTO all wrong, and building that relationship, again, takes time.

Many startups dream of being able to use student developers – folks who are still in school for computer science and are looking to bulk up their resume. The problem with that is, how do you find them? How do you know they’re good?

There’s a new startup out of Williams College that seeks to solve that problem: Algora. Algora does the leg work of reaching out to student programmers at fantastic schools and onboarding them onto the platform, where startups can post code bounties and students can complete them.

We at Lithobyte have used Algora for our own projects to great success, even hiring one of the students with whom we’ve worked. It seems to us that Algora is an excellent fit for many startups looking for the low cost and high quality that student developers can offer, without the hassle of finding them yourself.

/by
,

QA for Startups

Quality Assurance, or QA for short, is an important part of any app development process. QA helps identify potential issues before your app gets in front of users, which results in happy customers, more revenue, and lower development costs in the long run.

However, QA can also be a significant cost for a startup, depending on how much confidence in a product stakeholders require. QA can involve anything from just having someone open the app before you hit the final publish button all the way through a full-on QA Engineer writing extensive amounts of code that verifies the functionality of other code.

What it should not include, however, is developers spending cycles attempting to find bugs in the application they wrote. There are a few reasons for this.

First, developers are often one of the largest expenses in creating an app. Having your most expensive worker doing things that others are just as qualified to do is a recipe for going over budget.

Second, developers are notoriously bad at finding bugs in their own work – and it’s not because they’re stubborn, as tempting as that is to believe. The issue is that, as the architects of what actually appears on the screen, they have internalized the ‘proper’ way to do things. They know the way the system is meant to be used on an almost innate level, making thinking outside of that box difficult to say the least.

Third, developers think deeply about all the things that could go wrong in an application. Unfortunately, if they spent all their time preventing each of those things, the app would never be finished. Without a sense of how to prioritize various problems, developers will inevitably try to fix the wrong things – resulting in higher costs for the client.

As a result, LithoByte recommends one of two things: either including QA engineers explicitly in the project from the beginning, or have startup-internal contributors do some amount of testing themselves. If the former, startups should prepare for additional costs (though not as much as if they had no QA at all – you’ll pay for it now, or later, when your users report the bugs to you).

The latter (having a someone internal to the startup do testing), often means that the founder or a co-founder is testing out the application themselves. This is a good thing on several levels. As we’ve previously discussed in our article on bugs, founders often have a vision in their head of how an app should behave, but, through the process of reducing that vision to the imperfect medium of words, an incomplete version of that vision is communicated to the developers (not to mention the further translation into code). Having the founder frequently review the product has huge advantages, and allows the team to resolve discrepancies earlier in the process. This is often the cheapest, most effective way to accomplish QA.

Luckily, both Apple and Google have built in ways to test apps out before they get to live users. We highly recommend that, even if you have external QA consultants checking over the product, you also make use of the these tools to do internal testing by at least one stakeholder before releasing the application.

/by

Competing with Amazon/Google etc for tech talent

We’ve written in the past about how to effectively evaluate developers, and our company provides a service where we will act as independent evaluators for startups that don’t currently have technical skills. Today, however, we’d like to discuss how to convince a developer to join your early stage startup once you’ve found someone you want to work with.

The Money Problem

Most early stage startups have one major problem: money, and specifically, having too little of it. On the other hand, large companies like Google, Apple, Facebook, Amazon, and the rest, have tons of money – billions – on which to spend on talented developers. How, then, can these startups attract talented developers, and convince them to take the risk? Why would an amazing dev take $60k and no benefits when they can work for a large tech firm and get $300k to start plus amazing perks?

Reframing the Comparison

When you put it that way, it seems pretty bleak. But as a startup, you have to realize what you’re selling (to the dev, your investors, and, ultimately, your customers). As a startup, you’ll never be able to compete with one of the tech giants on money.

So don’t.

Instead, frame the comparison as one of impact and experience. That is, look at what your potential hire will have control over (that is, what they’ll be impacting) at your company vs. a tech giant’s, and what kind of experience they’ll get at your company vs. a tech giant’s.

First, impact. At a giant, they’ll join a team of other (very talented, certainly) developers, and after onboarding they’ll be given a very, very small task. “The designer said we need to shift this text field over 2 pixels.” “We need to show a timestamp on this page in this spot.” “We have a minor bug that you need to fix which hopefully you can get it done before the next release, but no worries if it takes longer.” Sure, they’ll be shipping code that affects a large number of users, but will they really own it? Can they say they ‘built this app?’ No. At best they’ll be able to point to a part of the app and say, “I helped with that.”

At a startup, it’s all them. As a first hire, every line of code is theirs. They wrote it. They answer for it. As a second or third hire, even a later hire, they’ll be building whole features and screens. Now that is power, that is impact.

As for experience, big companies want devs to specialize. They’re hiring you to do one (1) job: whatever it was they were hired to do. They’ll only be doing that, for some amount of time (usually on the scale of year(s)).

At a startup, they will have to learn things on the fly. Sure there will be some things they’ll focus on, but building a product from scratch requires a broad knowledge of the entire system and all related systems. This is a huge career advantage, since so many companies want so called ‘T’ shaped developers: devs with both broad knowledge of development processes in general and deep knowledge in one area.

Problem Solving

Lastly, at a startup, there’s never a dull moment. Everyone is responsible for building something, and it will be a huge challenge. Developers are in the business because they like solving problems; what, then, could be more fun than having the power, responsibility, and learning opportunities available at a startup?

/by

5 Tips on Starting a Business

So you want to start a business. Great! But where do you start? It certainly won’t be easy, but with a lot of drive, a little luck, and some savvy, you can maximize your chances of turning your dreams into a successful entrepreneurial endeavor. Here are our top tips for starting a business as smoothly as possible.

1. Choose your co-founders carefully.

More carefully than you would choose a spouse. You’ll be spending a LOT of time with your co-founders (probably more time than your actual spouse), and if things go sour and you find you simply can’t work it out, a business divorce is even worse than a regular one. You can’t split the custody of your startup.

2. Invest in a good lawyer, a good accountant, and good contractors.

You may be hesitant to spend a lot of money on these when you’re first starting out and cash isn’t flowing yet, but having professionals on your side from the get-go will save you headaches in the long run. A quality lawyer and accountant will help you set up your business properly and legally (and save you money on taxes), and quality contractors will ensure that your work gets done right the first time. (For more tips on saving money in the early years, check out our article on keeping costs down.)

3. Start small!

A business is a risk, so don’t invest too much too early. Come up with a hypothesis and test it with a small product that solves the biggest problem, not every problem. If your experiment has lackluster results, figure out why and be honest with yourself about how fixable the issue is.

4. Create a detailed plan.

Work out the kinks now, and be realistic about what you can get done. Simply believing that everything will work out isn’t enough; plot out exactly what success will look like and the steps you will need to take to get there. But! Make sure you’ve done tip #3, because creating a detailed plan for a sprawling project is a recipe for never getting started.

5. Don’t reinvent the wheel.

Instead of trying to invent an entirely new category, improve upon something that already exists; it’s often easier to be successful this way. Keep it simple.

What do you think? Have any tips of your own to add to the list? Leave them in the comments! And as always, feel free to drop us a line with inquiries, suggestions, and/or love notes. We’re always happy to hear from you.

/by
,

Mobile App Startups: Tech Stack

Thryv gets many questions about this, especially from startups who are still looking for technical co-founders. Where should you start? What technologies are easiest to recruit for, and what are their tradeoffs? Well, this article should give you a good starting point.

Server

Your server is where you store all the data that needs to be displayed. Almost every startup will need a server.

The in-vogue thing to do at this point, especially if you’ll be building both a website and an app, is to build a JSON API that sits on your server. JSON is a common format for communicating between different types of applications, and an API is a set of capabilities that an outside application can utilize.

With that in mind, the question is often this: what’s the best way to build a JSON API? There are several options.

Ruby on Rails

Ruby on Rails, or simply ‘Rails,’ is a very common and reliable technology. Rails has the advantage of being quick to setup. It’s generally pretty easy to add features to a Rails API, and there are tons of developers who know how to use Rails. The disadvantages generally come as you get larger; Rails does many things for you, so doing more specific things can start being more trouble than it’s worth. That said, the speed you gain at the beginning can often outweigh the costs down the line, and many prominent companies use Rails at scale.

Node.js

Node can be a very advantageous technology to use, especially when the developers who are helping you work primarily on the ‘frontend’ of your website/app. Node uses javascript, which is a vital frontend web technology, but it uses it on the ‘backend,’ meaning that developers who generally work on one can easily get up to speed on the other.

Python (Django or Flask)

Python is a beloved programming language in many circles. Building websites and APIs in Python is enjoyable for many developers because it is so easy to work with. It also has some advantages in raw speed without sacrificing much in the way of development velocity. However, it doesn’t have quite the same developer pool as javascript, and it can be a bit more work than Rails to get something up quickly.

Database

The most common database format at this point is probably PostgreSQL. Postgres, as it’s colloquially called, is robust and professional, and belongs to a family called ‘relational’ databases. It can be a little tricky to setup, but it’s the workhorse of many modern server applications.

For specific types of problems, a non-relational database may be preferable. In those cases, MongoDB is probably the most popular choice.

App

When building an app, there are tons of choices. In Thryv’s opinion, though, there are only three good ones.

Going Native

This means programming in Objective-C or Swift on iOS, or Java or Kotlin on Android. Going native gives you the highest potential for a quality app. iOS and Android phones are built and optimized to run native apps well, so they’re always a safe bet, especially when you’re targeting only one platform to start. However, it can be difficult for small teams to rapidly iterate on two separate platforms, in which case it may be wise to consider a cross platform approach.

React Native

React Native is the latest in mobile development from Facebook. It allows you to quickly build native looking apps on both iOS and Android at the same time. Moreover, since it’s in javascript, you have a large pool of developers who can work on your app. There are, however, downsides. React Native does not match native performance, and there are certainly things that are difficult to do with it. Additionally, since it’s a part of the javascript ecosystem, things move very quickly, which means they break often.

React Native, in our opinion, is a classic high risk/high reward technology.

Flutter

Flutter is a new cross platform framework from Google. There are some large technical differences between Flutter and React Native, but they break down to two things: speed and styling. Flutter apps, due to Flutter’s architecture, will run smoother and probably be easier to build than React Native. That said, Flutter limits you stylistically: if you like Google’s Material Design then it will be a fast, easy to use option for you, but if you want to deviate from Material Design, you may want to consider React Native instead.

Web

There are so many options for building a website today. Most startups generally need at least a landing page, but if that is, in fact, all they need, there are a myriad of solutions that they can use: WordPress, Wix, Instapage, Squarespace… and many, many others. If you need to build a dynamic website, there are a few technologies people generally use. All the technologies mentioned in the Server section apply here, but it can be difficult to make them work with an API as we described. As a result, we recommend React for your dynamic website needs. React is the foundation on which React Native is built, so if you’re building your app in React Native, you maybe able to share code between them. Otherwise, you may also consider a framework called Angular. Both allow you to build beautiful, modern websites with the highest level of flexibility.

Infrastructure

Where should you host your web properties? There are two places we generally use (and, in fact, one is built on top of the other).

Most startups eventually move to Amazon Web Services (or AWS for short), and any tech person you talk to will have heard of it. AWS offers a lot of flexibility, and is excellent at helping you keep costs down. Unfortunately, it can be hard to setup, and there are so many knobs and buttons to tinker with that it can be quite intimidating.

For this reason, we often recommend that startups start out using Heroku, a Platform as a Service (PaaS) offering built on top of AWS which takes care of most of the configuration for you. Your developers will be able to easily deploy your code with few tradeoffs when it comes to performance and cost.

Need help?

Do you need help deciding what kind of tech stack you should go with? Then contact us! We’ll be delighted to chat with you about what you need, and help you get it done.

/by

Keeping Startup Costs Down

Whether you’re funding your business yourself or seeking investors (for more on the pros and cons of each, check out our article on the subject here), it’s always a good idea to keep costs as low as possible when you’re first starting out. Here are our tips for saving some cash so you can get the most out of your business in its beginning stages.

 

Don’t hire employees until you absolutely have to.

In your first year, do as much of the work by yourself as possible. This will allow you to get to know your business inside and out, so by the time you do hire people, you’ll know exactly what you need from them. Many of the specific tasks you’ll need help on won’t come up often enough to occupy the time of a full-time employee, so hire contractors for those tasks when they do come up, or hire one multitalented person who can take care of many tasks. But don’t hire out the hard parts of your business until you’ve figured them out for yourself–if you pass these tasks off, they could be fixed inefficiently and you’d be none the wiser.

 

Work remote.

Online businesses often don’t need a physical location (especially when it’s just you), so you can save money on office space by working from home or anywhere with an internet connection. Doing this will give you a lot of extra cash and an edge on your less-frugal competitors.

 

Don’t cheap out on contractors.

As the saying goes, “If you think experts are expensive, wait till you hire an amateur.” If you’re going to hire someone to get something done, get it done right the first time, rather than many times cheaply. Sometimes cutting costs means investing in quality work up front.

 

Get a good lawyer and a good accountant.

Lawyers are always going to be expensive (use them only when you need them!), but again, investing in quality will end up saving you money in the long run. They can save you hassle by keeping you on the right side of the law as you set up your business, can write contracts to protect both you and your employees, and, when used in conjunction with a good accountant, can structure your business in a way that can save you a lot of money on taxes.

 

Follow these tips, and you’ll be well on your way to entrepreneurial financial freedom. Best of luck! And if your business needs an app, give Thryv a call–we’re happy to help.

/by

7 Mistakes People Make Trying to Find Technical Co-Founders

Finding a technical co-founder is hard, and every startup is different, so it’s difficult to say what you should do to recruit one (although we’ll be trying in a different article). On the other hand, it’s pretty easy to say what you shouldn’t do. Here’s our list of 7 mistakes people make when looking for a technical co-founder.

1. Ask them to “build it for you”

This is the most widespread and pernicious of mistakes, and easily takes our top spot. And it betrays a fundamentally insulting way of looking at your relationship with a developer.

If you’re looking for a technical co-founder (which you are, even if you’re just looking for someone who will build the product for equity), then you need to treat them like a partner. They have a valuable skill that you don’t, and their experience will allow you to not just create the product in the first place, but create a better product than you would on your own. You can’t treat them as though they are a completely interchangeable code monkey and expect to get a loyal, passionate partner out of it.

If you just want someone to ‘build it for you,’ then you’re not looking for a technical co-founder – you’re looking for a hired gun. Unfortunately, hired guns don’t work for free, and you need to be prepared to shell out a fair amount of money to have someone execute on your vision. There’s nothing wrong with that approach – it’s a large part of Thryv’s business – but it’s a mistake to treat a potential partner like a freelancer sans monetary compensation. Developers aren’t dumb, and, by and large, you won’t be able to just trick ‘some dev’ into making you rich in return for scraps (which is exactly how it can sound when you take this approach).

2. Ask for an NDA before talking about your idea

There’s nothing that screams ‘novice’ like asking for an NDA before talking about the idea.

It’s not that NDAs aren’t important – they are – but they are generally only relevant once you have a product, not when you’re still in the ideation phase.

When all you have is an idea you want the opposite of an NDA. You should be shouting your idea from the rooftops asking for feedback. You need feedback, you need people with experience to tell you what they think. Is it feasible? What do I need to build it? What haven’t I thought about? What problems am I likely to encounter? Are there competitors I don’t know about? What kind of timeline should I expect? These are all questions you’ll want to answer before attacking the problem in earnest, and if you demand an NDA before asking, you’re never going to get the answers.

“But isn’t that dangerous?” you ask. “Won’t someone steal my idea?”

No, and no. There is almost a 0 percent chance your idea will be stolen, even if it’s amazing. Why? Because the idea is one of the least important factors in success – and it’s important for you to come to terms with that. The execution, the team, the timing, the advisors are ALL more important than the idea itself. Those things also happen to be the hardest parts to get right, so until you show that you have gotten them right, no one will try to steal your company.

3. Over hype your idea

Inspiring the people around you is a vital part of business success. Over hyping, though, will actively repel potential partners.

No one is inspired by someone saying ‘this is a billion dollar idea!’ or ‘this will change the world!’ They become inspired when you tell them why – and when you show them it’s possible.

As an example: the concept of high speed transit between large cities has been around for a long time. So why was the Hyperloop so interesting? Because Elon Musk and his team wrote a whole report on how it could be done, along with realistic estimates of what sort of impact and possibilities it might entail. Strive to do the same with your own ideas.

4. Expect them to work for free

The key word here is ‘expect.’

When you’re starting out, you will almost certainly be cash strapped. You want to find someone who will help you make your idea into reality, and you can’t afford much at this point. Moreover, you want to work with someone who is as excited to work on the idea as you are. What are you to do?

Well one thing you mustn’t do is go to a developer and expect them to work for nothing. Any experienced developer has 1.2% of some failed company in their back pocket – adding another chunk of worthless equity has exactly zero appeal. It’s your job to draw them in over time, and one meeting where you tell them the idea won’t do it. A great way to get them to fall in love with the idea is give them exposure to it, with a monetary incentive to get them in the door. If, once they’ve seen the potential by working on it a bit, they want to join as a partner, then you can talk about equity only compensation – but no experienced developer will commit to something unproven, free of charge, after one conversation.

5. Act like your idea is unique

…because it almost certainly isn’t. Perhaps a part of it is, but that’s not the point, and it’s not what makes it valuable. Ideas are a dime a dozen; there are lots of ways to solve any single problem. What you need to do is show that the way you’re going about it is viable, and that you have the wherewithal to get it done. Moreover, thinking your idea is the only one in this space is almost always naive, and pegs you as a beginner – no one wants to work with a beginner.

Work hard to find other examples of similar ideas succeeding, or if they failed, find out why – and explain how you’ll avoid the same pitfalls.

6. Not doing research

If you’re looking for a technical co-founder, there are tons of questions that you need to answer. Even if you’re not technical, you need to have done some research about what you need to bring your idea to fruition – and be able to speak intelligently about your thought process.

This may sound like a chicken/egg sort of situation – if you need technical expertise to attract a technical co-founder, how are you ever supposed to do so in the first place? One way is to find a technical advisor who, while they’re not going to build your product, can point you in the right direction. Ask them what the critical decisions are, and what the trade offs are for different approaches. Consider your options, do your research, make some tentative decisions, and use that as a foundation on which to build your search for a partner.

7. String meaningless buzzwords together

No one is impressed with buzzwords. Buzzword salad immediately identifies poor partnership choices for many developers.

The most important part of any business is the problem it’s solving. Start with the problem, and build from there. If new technologies have enabled a novel solution to an old problem, all the better! But keep the problem at the center, and don’t use buzzwords if possible. People who know them will pick up on it and get a bad taste in their mouths, which makes for an uphill battle when trying to recruit them.

What do you think?

Anything we missed? Leave it in the comments. Have an idea you’d like to discuss with us, or need some advice? Contact us!

/by
,

Decreasing Bias in Hiring Technical Roles

Many tech companies are not terribly diverse. There are a lot of reasons for this, but today, I’d like to talk about some of the ways bias creeps into hiring, and what to do about it.

Coding Challenge Format

The standard whiteboarding technical interview is completely broken. It tests for skills that are practically orthogonal to modern software engineering – when a company I work with requires me to evaluate candidates based on a whiteboarding interview, I routinely walk out of them having no idea whether the person I just spoke to will be good at the job I need them to do. Few companies need programmers who can write code in high pressure environments, by hand, on a whiteboard, in front of an audience of other developers whose job is to pass judgement.

However, many companies do need developers who can translate business requirements into code, use the best tool for the job, and integrate it into existing codebases. Luckily, testing for such skills is pretty straightforward. I ask candidates to add a feature to a dummy product that is related to the business of the company hiring them. In this way, you can test how the candidate would write code in an environment that’s similar to the one they’re entering.

Now, whiteboarding is supposed to test for ‘problem solving,’ and many programmers would complain that this format takes away that part. So, I usually try to add some sort of twist to give the candidate a challenge or two so that we can evaluate problem solving as well as platform knowledge.

Evaluation

Another issue with whiteboarding is that it’s often biased in favor of white males. People have implicit expectations of who will be right and who will be wrong, and what a good programmer looks and sounds like. All of which has nothing to do with actually writing code!

There are plenty of examples where even submitted code gets analyzed in a more or less harsh manner depending on whether the name/screenname appears masculine or feminine (for instance, this study about gender and Github pull requests).

To mitigate this aspect of the process, it’s important to anonymize the candidate’s submitted code before evaluating it. I like to have the team review it with no names or other gender/ethnicity signifiers and then either have a conversation about, or numerically score it on various agreed upon criteria. Forming a ‘blind’ opinion helps inform the decision once the person comes to meet the team.

Culture

Having concluded the technical evaluation, it’s just a matter of determining cultural fit, which varies by company. In addition to the standard reference checking, I find it important to get to know the candidate outside of a work setting and ask them some questions on something they’re opinionated about. The key here is to see how they respond to that probing, and how well they can take into account someone else’s point of view – empathetic employees can almost always be reasoned with. If possible, I try to get people with several different backgrounds to meet with them, to see if they treat different groups differently. In this way you can not only hire diverse folk, but develop a culture that welcomes people from diverse backgrounds.

 

/by