, , , ,

Client Spotlight: Tapper Legacy

We’re delighted to announce the launch of Tapper Legacy!

Tapper is an incredible opportunity to share your stories with your family, friends, and loved ones. You will never have to leave anything unsaid or any story untold. It’s an app where your legacy can live on for generations to come.

We built this app for Tapper Technology from the ground up as a foundational product – meaning they will be able to reliably build upon it into the future. With a tech stack including Rails, Swift on iOS, and Kotlin for Android, we were able to quickly and cheaply build an MVP that will allow them to hire from a large pool talented developers internally when the time comes, quickly iterate on new features, and not sacrifice on quality.

Download the Tapper Legacy app today and start safeguarding your legacy!

/1 Comment/by

Fixed Price and the Illusion of Control

When clients come to us, especially new clients, we often get asked to work with them on a fixed price basis. The reason for this usually boils down to a desire to contain the costs and limit the timeline. If you want a project to only take so long and cost so much, why not bake it into the contract itself? Or so the thinking goes.

Paradoxically, however, fixed price projects do nothing to contain the risks of an overpriced, extended-timeline outcome, and, if anything, make them more likely.

First of all, something everyone agrees upon: a startup is a risk. Uncertainty is the only certainty when building a new thing. Before product-market fit is achieved, your product will necessarily go through a multitude of changes, and it is nigh impossible to predict those changes from the outset.

Second, in a situation in which things can and must change frequently, the best way to hamstring yourself is to create a fixed, inflexible plan at the beginning. Imagine, for a moment, that you and your consultant agree to a fixed price contract with milestones, timelines associated with those milestones, and payments to be made on successful implementation of those milestones. After a few weeks and some user interviews, it becomes clear that drastic changes need to be made to the product if it is to ever be successful. Unfortunately, your consultants are contractually obligated to complete the project as specified in the contract. Worse, as the consultants deliver on those milestones towards a product that is now useless to you, you will be contractually obligated to pay them for it anyway!

Finally, fixed price projects, fundamentally, are attempts to shift the risk from the client to the consultant – meaning that the consultants will have a fiduciary obligation to give a quote that is far above what I think it will cost to do the project. In such a situation, the incentive changes from “how do I build the best product possible” to “how do I turn a profit even in a worst case scenario?” A consultant will then run through some scenarios and how much they would cost to fix – and then set the price to cover those worst case scenarios. This often:
– is the exact opposite of what the client is trying to achieve by asking for a fixed price (namely, contain the costs),
– sets up an adversarial client-consultant relationship, since now the consultant must say no to any changes proposed by the client,
– greatly restricts flexibility, resulting in an ineffective product, and
– results in a lower quality product overall by incentivizing an extremely conservative approach in the consultant.

Our goal is to provide clients with the best service resulting in the best product possible – and fixed prices prevent us from doing that. This also seems to be the consensus among the best developers we’ve worked with, and who are also reluctant to work under fixed price contracts.

Time and materials projects, on the other hand, give the client ultimate control over the cost and timeline of the project. Consultants work at the direction of the client, and the client determines what is worked on, when, and for how long. This allows them the flexibility to change course when required, to cut their losses on features that aren’t worthwhile, and respond quickly to user feedback. Paradoxically, by NOT agreeing on a scope, a price, and a timeline, clients are much more likely to achieve all three.

/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
,

Mobile App Startups: Where to begin?

There is a lot that goes into making an app idea into a reality, and once you start thinking about how to actually get it done, the whole endeavour can be daunting. Often, breaking huge tasks into smaller, more manageable ones can help make things less overwhelming. In that vein, let’s break down ‘starting a company’ a bit.

Generally, you need to decide on a strategy on three fronts: capital, marketing, and tech. More in depth articles on each of these are forthcoming, but first, let’s talk about what they are and why you need to think about them.

Your capital strategy basically relates to how you’re going to pay for things, or perhaps more accurately, who is going to pay for things. There are two main categories for this: either you pay for things yourself, or you get someone else to. There are advantages and disadvantages to both, and huge challenges as well. This is one of your biggest decisions, because it may entirely determine your strategy in the other two areas.

You need a marketing strategy because you need to build buzz long before your app comes out. Being able to show interest in your product can also help with raising capital and attracting a tech team. Finally, it can help you find early testers who will give you feedback before you go primetime – which is invaluable.

Lastly, your tech strategy. What technologies will you use to build your app? Who do you know that builds with those technologies? What do you need to think about as your app grows? How much will it cost at the beginning? How will that cost grow with your app’s popularity? Realistically, how much use will your app get? These are all important questions that will shape your tech strategy.

LithoByte has helped many startups develop their strategy in all of these areas. We’ve seen it all, and are intimately familiar with the pluses and minuses of each approach in each category. Do you have a question? Get in touch with us and we’d be delighted to talk to you about what you need to do to get your idea out there!

/by
,

Mobile App Startups: Raising Capital

This topic is one of the most opaque for many entrepreneurs, and is different in every case. Some general paths can be described, though. There are two main options: using your own money, or using someone else’s.

Using your own money

Using your own money is generally referred to as ‘bootstrapping.’ Often, because it’s their own money, entrepreneurs spend less overall when bootstrapping than when running the business with investors’ money. This can express itself in many ways: keeping your day job and building your business after hours, paying people in equity, not having an office, and doing as much as you can yourself.

The advantage of bootstrapping is that you don’t owe anyone a return on their money, so if things drag on and on, you don’t have a bunch of investors breathing down your neck. You can take your time, build slowly, and make unhurried decisions about your business. It’s hard to run out of money when you’re not spending any (or spending very little).

The disadvantage is that often, quality is expensive. Paying people in equity is not always an option, and indeed, it usually isn’t for people who know what they’re doing. You either have to take a risk on someone inexperienced, pay a lot of money out of pocket, or do whatever it is yourself. None of those are necessarily bad things for your business; they’re just either risky or unpleasant.

Finally, for many entrepreneurs, a problem with bootstrapping is that it isn’t glamorous. Don’t fall into this trap! Just because your friends won’t be impressed by your after hours project doesn’t mean you should try to raise money from venture capitalists. Be aware that your ego could try to convince you to do things that are Bad For Your Company, and try to look at your situation dispassionately.

Using someone else’s money

 

There is a standard path that startups go down when looking to raise institutional capital.

Usually, it starts with what’s descriptively called a ‘friends and family’ round. Predictably, it involves asking your friends and your family for money in order to make your idea a reality. Parents, rich uncles, that lawyer friend of yours are all fair game. You’ll probably want to prepare some designs of what your app will be, since it’s always easier to support something you can see. This round will most likely involve getting money in convertible note form – basically a loan that turns into equity if things go well. This way, you can give your investors some piece of mind that they’ll get their money back if things go poorly, but also get a piece of the company if it takes off.

After using up the money your family and friends gave you on building a prototype of your app (we have lots of blog posts about how to do that correctly), you will hopefully have some sort of success. You’ll then start wanting to talk to Angel Investors. Angels are high net worth individuals who will give you something in the five to six figure range to get your app ready for prime time, add more features, or simply scale up your operations. They’ll take equity, and depending on the Angel, want some sort of input into how the company is run.

Finally, you may get to a point where you want to talk to the heavy hitters: Venture Capitalists (VCs for short). VCs really don’t care about you unless you have 10 million users or $1 million in annual revenue. They’re wanting to make big investments for a huge return – usually they’re looking exclusively for potential billion dollar businesses. If you can’t convince them that your market is large enough to support a billion dollar business, and that YOU are that business, they won’t be returning your calls.

VCs typically make investments in the seven to eight figure range and expect a lot of equity. They also want a lot of control over the company, so that if they think you’re doing a bad job, they can take it away from you. VCs can be like dealing with the devil, but they can also be amazing resources. They know tons of people who can help you, and are heavily invested in your success.

Conclusion

This is a deep topic, and there are a multitude of books written about it. And to be clear, these paths aren’t terribly clear cut, so you can mix and match as necessary. Regardless, LithoByte is here to help every step of the way; we’ve seen it all, so take advantage of our experience and get in touch!

/by