, , , ,

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!

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.

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.

,

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.

Anatomy of a Bug

Many non-technical stakeholders believe a bug is exclusively the result of programming ‘mistakes.’ However, this is often not the case; there can be many causes for what people colloquially refer to as “bugs.” In this article we’ll go through some common ones, but first, let’s provide a definition of a bug.

What is a bug?

Fundamentally, a bug is a mismatch between how the user expects a product to behave and the way it does behave. (In fact, one of the most common formats for reporting a bug includes a description of the expected behavior and the actual behavior, both of which are required to specify the bug.)

Causes of bugs

Now let’s take a look at common causes for bugs, keeping the above definition in mind.

Programming for safety

Developers think hard about what can go wrong in a product, and how to prevent such situations from arising. In the process, programmers often make certain actions impossible, so as to prevent users from accidentally doing damage to the system. However, for an end user, this can be frustrating, and even result in a bug report.

As an example, imagine a product built to allow collaborative form editing: it has fields created by an admin, and workers fill out the form. Now suppose the admin decides that a field is positioned improperly, and so attempts to delete/recreate the field in the right place. When they go to save the revised form, however, the old field is still there. The company then reports this to their developers as a bug.

Is this a bug though? Let’s consider. When building the product, the developers considered data loss to be a worst case scenario, so they made it impossible to lose data (this is a good thing!). When the admin attempted to delete the old field, this would have resulted in all the previous data that workers inputted to it to be lost – so the system behaved as designed and prevented that loss.

However, obviously, this is preventing the user from doing something they want to do. It should be changed in some way or another. But ultimately, this isn’t a mistake per se – the system was behaving in the way it was designed, and it was designed in a reasonable way. While it was reported as a bug, it amounts to a new feature request.

Unsupported behavior

Similarly, sometimes a user will attempt to do something that the system does not support. As an example, consider a business equipment rental application, wherein a user can submit a request to their project manager to rent some equipment.

A bug is reported to the developers of the application: a user has attempted to submit a rental request repeatedly, but the application reports an error each time. However, upon further investigation, the user was attempting to insert emoji into the comment box – which is not supported by the database.

Is this really a bug? Had the consultant, from the beginning, suggested that supporting emoji be a top priority, the client would have balked – the application is for business purposes, so supporting emoji would be an unnecessary expense. If the client wants to support emojis, then that would reasonably be a feature request.

Overuse of a supported feature

If you’re familiar with the term DOS, then consider this as an accidental DOS attack. Sometimes users will make use of a feature far more than the developer (or business!) expected. For example, suppose a social media application has a feature wherein a user can upload a series of photos and the application’s server will generate a collage from them. As long as only a few people are using this feature at a time, everything works well – however, if the feature suddenly becomes very popular, it might end up overloading the server.

Is this a bug? If so, it’s a wonderful bug to have – it means that your service is popular! However, it obviously needs to be handled, and, again, a new “feature” would need to be requested to support the popularity of the collage making function.

Unexpected combinations of usage

Apps are complicated; they often involve tens or hundreds of thousands of lines of code. Users, too, are complicated. When these two sorts of complications interact, the results are often unexpected. We at LithoByte have often seen startups be shocked by how actual users end up using their app – not seldom is it ways that are completely counter to the way it was designed.

When a system’s features aren’t designed to be used together based on the client’s expectations of end user behavior, strange things can happen; and sometimes those strange things are reported as bugs. The important thing to remember here is that startups have limited resources – so planning for every possible use case is combinatorially, not to mention financially, infeasible. Again, if it comes up, it certainly needs to be resolved, but it is not a mistake, per se.

Miscommunications

When a startup founder describes their product, they have a complete vision of it. However, reducing that vision to the imperfect medium of spoken or written language will necessarily result in an incomplete picture. When a developer then takes that incomplete description and attempts to translate it into code, even more of the original vision will be lost. (This is one of the many reasons LithoByte recommends an iterative approach to development – it allows us to work with our clients to, with time, bring the actual application closer to their vision of it.)

Miscommunications are a part of the process and happen in every project. When a product is designed differently than the stakeholders intended, it is an opportunity rather than a failure. By allowing lots of opportunities to identify miscommunications, you end up with a better product overall.

Genuine oversights

Given the above, a relatively small proportion of ‘bugs’ are actually oversights or mistakes. However, every piece of software is imperfectly built – the question is not if a product has bugs, but whether they bother end users enough to cause a company to lose money. In this way, rather than trying to aim for a bug-free application, aim for one that users enjoy using. That doesn’t mean that everything they try to do with it will work – only that users will give you the benefit of the doubt. And when you run across a genuine oversight, which at some point you almost certainly will, it’s important to regard them as an unavoidable part of the process, fix them, and attempt to prevent them from happening again.

Client Spotlight: Babblbox

Welcome to another edition of LithoByte’s Client Spotlight! Today we’re profiling Babblbox, an iOS app for finding cosplay costumes.

The newly released Babblbox app streamlines the process of finding and purchasing cosplay costume items. These folks have put a lot of work into combing through many different cosplay websites so you can easily search for the items you need to perfect your costume.

One of the things that’s impressed us about Babblbox is how thorough and methodical they are about crafting their product. They’ve been doing tons of interviews with users to make sure the app they’re building is something that end users actually want to use. They’re also building an incredibly detailed list of fandoms, characters, and versions of characters, as well as personally reaching out to people who create cosplay costumes on commission to offer their services through the app. It’s an incredible amount of work, and they’ve been organized, meticulous, and thoughtful throughout.

They’ve also been very clever and practical about their release goals. Due to their ruthless dedication to an MVP ethos, LithoByte was able to complete the first version of their app just 3 weeks after development began. Anyone who’s built any sort of reasonably complicated app knows that’s an outrageous timeline, and it’s only through their dedication to simplicity, ease of use, and their pragmatism towards highly desired but time-intensive features that we were able to get something done that fast.

The app is currently very simple, calling out popular genres, providing a searchable list of costume items, as well as a list of costume commissioners; we’ve seen the big plans they have down the road, and we’re excited to continue working with them.

The Babblbox app is available on the App Store now. Check it out!

Publishing your Android Application to the Google Play Store in 3 easy steps

This guide is intended to show you how to publish your Android application to the Google Play Store while following best practices.

Before publishing an app to the Play Store, you will want to create a Google Play account and pay the one-time developer registration fee of $25. Once you have this taken care of, you can move onto the developer console and create your first application. 

Suppose you have been working on application and you’re happy with how it currently works. After you have finished your  application and created a developer account, you will be faced with a somewhat overwhelming list of requirements, but fear not! We will guide you through everything 😄

Android Studio Bundling

In Android Studio go to Build>Generate Signed Bundle. This will launch a pop up and you should choose Android App Bundle because of Google’s new Dynamic Delivery Model. With the Android App Bundle, Google optimizes for each device that the app is launched on. APK is just a singular instance of your application.

Key Store Generation 

Every application you publish needs to be signed so that Google can verify that you, and only you, are publishing the app. In order to sign your application you can either let Google take care of it or you can have the key on your local machine. I am somewhat skeptical of Google so I would rather generate my own key and manage it.

1. Generate a key store which essentially behaves as a storage for all the unique keys of your application.

2. Create a key alias and a password.

3. Make sure that you check this box so that your key can be used in the Play Console.

Google Play Console

Hit the blue button that says publish an app on Google Play. You will need to check off the items from the left hand side before you can roll out your new app.

App Release:

Google has many tracks where your application can live. In this guide we will only discuss rolling your application out to production since it can very complex with A/B test, Alpha/Beta Launches, etc.

  • Production: In the second step of this tutorial we will talk about Android Studios Bundling feature that makes it simple to create and sign an app bundle. More about that later. After all the other steps are finished you will be able to rollout your app to production

Store Listing: (Everything in this section is required)

  • App Name: Short, sweet and memorable.
  • Short Description: 80 characters specifying the basic functionality of your app. Here is your change to give someone an executive summary of your application.
  • Long Description: Here you can give more in-depth details of your application and how you’re better than the competition!
  • App Icon: What people will see first in the Play Store.
  • Screenshots: Up to 8 screenshots per listing on the Play Store. Make them count.
  • Feature Graphic: Here you can display the key features of your application. It is recommended that you create a promotional video of your application in action to attract new users. Luckily Android has some tools that allow you to capture your app screen.Navigate to the bottom left of your Android Studio and click on the camera when you are ready to take a screenshot.

  • Content Rating: After you upload your application and fill out the content rating survey on the left side of your dashboard, you must assign a rating to your app. We recommend going with the rating assigned by Google since they ultimately control what gets published onto the Play Store.
  • Contact Email: If users need to contact you about any bugs in the application.
  • Privacy Policy: Many App Distributors require apps to have a privacy policy. Google requires a privacy policy for applications that are published on the Play Store. In our experience we find it best to hire a lawyer and create a general privacy policy for all the apps you would want to publish. This ensures that you are not vulnerable for any lawsuits in the future.

Content Rating

After you upload the Bundle in the App Release section, you will be able to establish the content ratings of your application.

This process is fairly straightforward and if you answer everything truthfully, you will have no problems!

App Content

Is your app safe for kids? Do you allow there to be harmful content? Are there any ads on your application?

Pricing and Distribution

Which countries do you want your application to reach? Is your app free or is there some fee? For now we will assume you are publishing a free application to all the countries in the world since paid apps introduce another level of complexity. Make sure your application is GDPR Compliant if you’re distributing to the EU.

Launch

After all these tedious steps, you are ready to roll out your app to the Play Store. Head to the App Release section and roll your app out. It will take about a day for Google to review your application.

After your app is public, Google provides robust data analytics and crash report data about your application.

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?

Client spotlight: Precious – Baby Photo App

Precious is an app that uses Artificial Intelligence to find the absolute best photos of your baby and uses them to create photo stories that will melt your heart (and is one of Thryv’s clients). It’s the cutest way to track your baby milestones and see your baby’s development. The app automatically organizes your baby photos into adorable monthly pictures, a time lapse slideshow, a photo calendar journal, and much more — all with no work required from you.

Precious came to Thryv to help them streamline automatic slideshow creation in the app – they were having issues with creating videos over ~12 minutes long. We helped break down their code into manageable chunks, vastly improved the algorithm’s efficiency, and worked out the bugs in their slideshow videos. Now the only limitation on how long the videos can be is… how much disk space the device has!

We’ve also implemented some pretty awesome AI algorithms for them (if we daresay so ourselves) using concepts from functional programming and the most cutting edge research on image processing.

Do you need help making your app fast, efficient, and profitable? Get in touch with us and we’d be delighted to make your app the best it can be!

SUBWAY:NYC – a Better New York Subway App

SUBWAY:NYC is an app for the New York subway that gives you all the features you need while staying easy to use. The app provides everything you expect from an NYC subway app: an interactive map, train arrivals, directions, favorite stations; but it also gives you some features you won’t find anywhere else.

You know how you’ll be sitting on a train, scrolling through your phone, and waiting for the next gram to insta, but everytime you pull into a station you have to login to the wifi again? And then by the time you’re logged in, you’re already in the tunnel again? Well SUBWAY:NYC takes care of that for you: as soon as your phone connects to TransitWirelessWiFi we’ll log you in automatically.

And we all know how bad the train arrival estimates are on those little countdown clocks are – so we decided to crowdsource where the trains are. Now when you view a station we tell you if a train was spotted at a nearby station recently so you don’t have to guess.

Download the best New York subway app today to get all these features and more!