Our first hire is moving on

company business

When I started BiteSite, I was really excited to see what I could do with the company. As a business owner, I found myself constantly looking for milestones that led me closer to running a 'real' business. I remember when I registered the business name, I remember when my friend got me a Freshbooks (http://www.freshbooks.com) trial for my birthday, and I remember purchasing the bitesite.ca domain. Each step along the way - I felt more legit.

But the ultimate was when I made my first hire.

Building the team was always a huge importance to me and still is. Even though it went against business sense, I was adamant about hiring an employee rather than a contractor. I wanted the sense that this person was really part of BiteSite and would help shape the company. That first hire was Ryan O'Connor.

I met Ryan at the University of Ottawa when I was teaching a Ruby on Rails course there. The first thing that struck me about Ryan was the way he helped others. Although becoming rarer these days, programmers can sometimes develop an ego and Ryan was the complete opposite. He clearly understood things better than others but never let that get in the way of helping someone out.

We were lucky to have Ryan say yes to working at BiteSite. He was taking a chance as the first employee of a new startup. But he did join us in 2015 and has been killing it ever since.

Ryan has brought so much to BiteSite. He brought strong development practices from automated tests to up-to-date frameworks, he helped create a welcoming mentoring atmosphere to new employees, he embraced our 20% Free Time Fridays and developed a lot of amazing stuff. On www.internationalsafety.com alone, he brought some stand-out features like e-Commerce, the Activity Feed, and real-time Task updates. He has become an incredibly strong developer in Ruby on Rails and React - but overall just an outstanding engineer, employee, and person.

The biggest thing an employer can ask for of his/her employees is trust - trust that they'll do the right thing, trust that they'll express themselves, trust that they'll do their best - and with Ryan, we had that in spades.

Today is Ryan's last day at BiteSite and it was amazing to have the chance to work alongside such a great individual. He starts his next adventure at one of our former clients, Splice (http://www.splice.co). I know he'll do amazing things there and wherever he ends up in life.

Thank you, Ryan, for all that you've done in helping me realize my dreams.

Casey Li
CEO & Founder, BiteSite

The Pros and Cons of Custom Software

software business

When you run a business, you may inevitably hit a point where you decide that software can help. Whether it be a website for marketing purposes, an app to help with automating workflow, or a solution to give you an edge over your competition, software can solve many use cases and bring many benefits.

But as you start to navigate the world of software you may be faced with information overload and have trouble deciding which route to go.

When dealing with business problems that can be solved with software, generally your solutions fall into two major categories:

  • Existing Applications
  • Custom Software
    • Custom Software involves hiring a team to build a piece of software specifically for you and your needs. We sometimes refer to the companies behind these pieces of software as “Services companies”. BiteSite falls into this category along with TWG (https://twg.io/) and Thoughtbot (https://thoughtbot.com/).

In this article, we explore some of the biggest pros and cons to choosing custom software as opposed to the alternatives.

PRO #1: Custom software solves your specific problem

The number one reason businesses choose custom software is that none of the alternatives truly solve their problem. Existing applications may come close, but may be missing one or two key features. A lot of times this happens when businesses are in very specific niches or have complex workflows that are not common. They’ll try what’s on the market and end up not satisfied with anything out there. Product companies typically develop software that suits large markets with common issues. If you find yourself in a smaller market that’s not served by existing applications, custom software is a great way to ensure that your chosen solution actually solves your specific problem.

PRO #2: Custom software is optimized for you

When exploring existing applications, they may solve your problem, but they may also solve 100 other problems. There are a few issues with this. First, all these extra features can clutter your experience and get in the way of what you really need. Secondly, all the extra features may actually be overwhelming leading to a frustrating user experience. And third, you may be paying for a lot of functionality that you’ll never use.

With custom software, in general, the features that go into the product are completely dictated by you and your business. This way you can ensure that only what you need goes into the product and nothing more. Furthermore, with a reduced feature set, you get the added benefit of quality over quantity.

PRO #3: Custom software teams are hired to work for you

When using existing applications, they may be incredibly powerful and feature rich, but consider for a second that they may also be serving hundreds of thousands of customers. 95% of the time the app may work great, but there may be 5% that doesn't work so great. So you call up the support team and you make a request to add a feature. The problem here is that your feature request might be competing with hundreds of thousands of other customer requests. While product companies will do their best to address your problem, the reality is they may not get to it for another year or more.

With custom software, you can be sure that your voice will be heard and that the features you want will be prioritized because you'll have a more direct line to the team and the team is generally serving fewer customers. The extra money that you pay for custom software gives you dedicated resources to solve your problems.

CON #1: Custom software is expensive

One of the biggest and most obvious reasons to NOT choose custom software is cost. Existing solutions can cost as little as $10/month, whereas custom software can run you literally tens of thousands of dollars a month. The best custom software is rarely a small 1 to 2 week project. Building custom software requires a solid understanding of the business and their problems, robust software practices, and dedicated resources. This all adds up pretty quick.

CON #2: Custom software takes longer to get up and running

Custom software is typically developed from scratch or at least from a basic framework. When it comes to features, not a lot comes for free. Thus, building everything to your expectation can take a long time. Even the most basic features we take for granted may take some time. For example, you may request the ability to allow users to log in. Simple enough right? Well, what if people forget their password? Ok, let's add a 'Forgot your password?' feature. Well, what if people want to delete their account? Ok, let's add the ability to delete your account and so on and so on. Each one of these features may take a significant effort to design and implement. With existing applications, you can be up and running in literally minutes.

CON #3: Custom software can suffer from lower quality

When talking about the pros - I mentioned that a reduced feature set can lead to higher quality. This is a result of the team spending more effort on fewer features. However, there is another factor that works in the opposite direction.

Generally, Product companies have way bigger teams. With services companies, you may have a team as small as 1 to 10 people working on your project. With product companies, you may have thousands or people working on a single product. Granted, typically product companies are working on products that are more complex, but having a larger, more diverse team can lead to higher quality software. This is not a certainty, but the best product companies in the world are typically doing some of the best work in the industry. That being said, service companies like TWG (https://twg.io/) and Thoughtbot (https://thoughtbot.com/) are really pushing the boundaries of software as well. And is some cases, product companies will acquire service companies because they are so strong in their field.

So, what should you do?

There are many more pros and cons aside from the ones I’ve discussed here, but the important thing is to choose the right tool for the right job. There are situations where existing applications are definitely the way to go, and there are other situations where custom software is the answer. Even though BiteSite is a custom software service company - many times we will forward potential clients onto existing applications because it makes more sense for them.

Deciding can be tough, but there is one saving grace: existing applications are generally cheap to experiment with. You could pay $10/month to try out a cloud product or even sign up for a free trial. If you’re not happy with it, you can start to explore a custom software solution. No huge loss.

The important thing is to do a little research up front before diving deep. And in my experience, people from both sides will give good advice even if that means directing you away from their business.

Casey Li
CEO & Founder, BiteSite

Homebrew install of PostgreSQL won't restart properly

coding software

Alright, let's say your computer didn't shutdown properly, and you're running the PostgreSQL service (via homebrew or other mechanism). You may try to restart the server and it may tell you that there was no problem, but you still can't connect.

What's most likely the culprit, is that PostgreSQL still thinks you're running the server via it's Postmaster ID file.

So what you can try is removing that file

rm /usr/local/var/postgres/postmaster.pid

And then restarting. That will probably help you out.

For a full detailed description of this process, check out https://coderwall.com/p/zf-fww/postgres-on-osx-with-homebrew-not-running-after-osx-crash

Casey Li
CEO & Founder, BiteSite

Stripe.js Bank Accounts: Invalid transit number. The number should be in the format xxxxx-yyy or xxxxxyyy.

coding software

This is going to be a quick one. I was working on a client project that uses Stripe Connect. We were using Stripe.js V2 to generate tokens for bank accounts. However, everytime I tried to use the test account numbers, I kept getting this error:

Invalid transit number. The number should be in the format xxxxx-yyy or xxxxxyyy.

After looking around a bit, I realized it was a really stupid error. I was trying to test a Canadian account, but when I went to look at the test accounts that Stripe provides, "United States" was selected. So lesson of the day, when testing Stripe Test Bank Accounts, make sure you select the proper country.

Hopefully that helps out some peeps.

Casey Li
CEO & Founder, BiteSite

Swift PUT and PATCH requests not sending httpBody

coding software

Hey everyone, this will be a quick one.

I'm finally coding a Swift iOS app to interface with my Rails app and I'm now at the point where I'm starting to implement PUT or PATCH requests for my record updates.

For my requests, I have a basic APIController that runs this code to build the request:

urlRequest = URLRequest(url: url)
urlRequest.httpMethod = "PATCH"
urlRequest.httpBody = bodyString.data(using: .utf8)

This method generally worked perfectly fine for my POST requests, but for some reason PUT and PATCH requests were not sending the httpBody.

Turns out, for PUT and PATCH you need to be explicit about the content type. Since I was using form urlEncoded data (so something that looks like "key=value&key=value&key=value" I just had to add this line:

urlRequest.addValue("application/x-www-form-urlencoded", forHTTPHeaderField: "Content-Type")

And then everything worked.

So final code looked like this:

urlRequest = URLRequest(url: url)
urlRequest.httpMethod = "PATCH"
urlRequest.addValue("application/x-www-form-urlencoded", forHTTPHeaderField: "Content-Type")
urlRequest.httpBody = bodyString.data(using: .utf8)

Hope that helps out some peeps!

Casey Li
CEO & Founder, BiteSite