Introducing Trello Views!

custom software trello software development

So we use Trello - a lot.

We use it to manage our Scrum Express process and it's become an integral part of our software development. However, one thing we noticed is that our Trello boards are getting BIG. Like super wide with lots of columns.

The thing is though, at any given time, we only need to see a subset of those columns. For example, when doing Product Management meetings, we're concerned with a very different set of columns than when we're doing development.

So - we built a Chrome extension to solve this. We call it Trello Views.

Super MVP at this point, but would love some feedback.

Check it out:

https://chrome.google.com/webstore/detail/trello-views/ljfoaeaaojcefkmljglbbphcoclnodnm

Casey Li
CEO & Founder, BiteSite

Carrierwave-AWS and fixing Excon::Errors::SocketError Broken Pipe Errors

custom software software development ruby on rails

So we've been using Carrierwave for a while. It's an amazing solution for Ruby on Rails apps that need to store files.

We use it mainly with Amazon AWS S3 as our storage. However, recently when trying to use it for a new app, we kept running into these errors anytime we tried to upload anything to S3. The errors were Excon::Errors::SocketError Broken Pipe errors. Most posts on the internet suggest issues with permissions or with not setting the region properly, but after trying all those, we still couldn't get it to work.

We then came across a Stack Overflow answer that talked about using an alternative gem called Carrierwave-AWS.

I was skeptical at first, because I wasn't sure who was maintaining it and why I hadn't heard of it before. As it turns out, this is maintained by the same people who maintain the original CarrierWave!

This new library uses the official AWS-SDK library and actually solved my Broken Pipe issues! What's more, I was happy to see that I could still revert to using file storage for dev environments with this library. All pretty sweet!

So if you're using Carrierwave with AWS S3 and you haven't heard of Carrierwave-AWS, it's probably a good time to check it out!

Here's the link: https://github.com/carrierwaveuploader/carrierwave-aws

Enjoy!

Casey Li
CEO & Founder, BiteSite

Why choose Off-the-shelf Software over Custom Software?

business custom software

For those who don’t know, my name is Casey Li, and I run a business that provides Custom Software services. So it might be a bit strange to see an article from us that talks about why you should NOT choose Custom Software.

However, the reality is that a lot of times when we talk to new customers, we recommend that they go with a solution that we cannot provide. We believe that if we try to sell everyone on Custom Software - even to the ones that it doesn’t make sense for - then not only will they suffer, but we will too. They will end up spending too much money and time and end up with something that they are not happy with. Meanwhile, our team will consistently fail to meet expectations and sour the relationship.

With that, I’m writing an article on why it’s best to consider one of the alternatives: Off-the-shelf Software.

What is Off-the-shelf Software?

There are other names for the type of software that we are calling “Off-the-shelf Software”. Some people call this “Commercial Off the shelf software” and we’ve referred to it as “Mass Market software” in previous articles. What it boils down to is software that is already made and available to use for the public.

Nowadays, most of the time, this takes place in the form of something you can easily buy online and either download to use, or simply use through a browser like a website.

Examples of Off-the-shelf Software cover a wide range of uses. They include Microsoft Office, GMail, Quickbooks, Spotify, Adobe Creative Suite, and more.

Generally speaking, if you can go online and purchase it (or use it for free), you’re most likely dealing with Off-the-shelf or Off the shelf software.

What is Custom Software?

Custom Software, on the other hand, is software that doesn’t exist yet. It’s software that you pay someone or some organization to build specifically for you to solve your problem.

What can Off-the-shelf Software do for your business?

Why are we even talking about this in the first place? Usually when you’re considering your options like Off-the-shelf Software or Custom Software, you’re usually looking to solve a problem. Very commonly, you run a business and you’re looking for some tools to help your business.

You might be looking for some software to manage your accounting - something that can keep track of your expenses, invoices, and time tracking. You might be looking for something to manage your staff’s schedules. Or maybe you’re looking for software to run email marketing campaigns.

Either way, most of the time you’re looking for something to augment your business and the reality is, if you have a problem to solve, there is a very high likelihood that someone has built software to solve it.

Why choose Off-the-shelf Software over Custom Software?

Ok, so now that you know what Off-the-shelf Software is and what it can do for your business, what are some of the reasons you would choose it over Custom Software?

Timing

One of the best things about Off-the-shelf software is that it’s available right away. If you need to solve your problem today, or just want to try out the solution, you can start implementing your solution today. In fact, most web applications today can be set up within minutes.

For example, you need an invoicing system, you could easily sign up for an account on Waves (https://www.waveapps.com/) or Freshbooks (https://www.freshbooks.com/). Within minutes you’ll have access to a very powerful invoicing tool.

If your problem is urgent, or time sensitive, or you realize the importance of moving fast on a solution - then off-the-shelf software is probably right for you.

Price

Companies that build off-the-shelf software typically rely on economies of scale and not relying on a one-to-one relationship between the hours spent building it and the money they are charging for it. As a result, most of these companies are able to charge a very reasonable price for a very powerful piece of software.

For example, let’s take Figma (https://www.figma.com/) as an example. Figma is a very powerful tool that lets designers create wireframes and user interfaces. Figma starts at $0.00/month and only goes as high as $45.00/month. For what you get and for what you can produce, this is quite cheap.

What’s more, is that a lot of these services and platforms price their software per user or per usage. What that boils down to is, the more successful you are, the more we’ll charge you, but that also means, if you’re small today, we’ll charge you less.

So not only is paying to use off-the-shelf software generally cheaper than building your own custom solution, it’s also generally cheaper to try out.

In some cases, the costs savings can be quite substantial.

Feature Set

This kind of goes hand in hand with Timing and Price. While Custom Software can get you all the features you could ever want, Custom Software is built from the ground up which means it can take a lot of time and money to get those features built, up and running, and ultimately to a state where they are operating well.

On top of those exciting new features that you want built that Off-the-shelf software doesn’t offer, even basic functionality that you’ve come to expect can take some time to get in there. For example, a sign up and sign in screen, a forgot password screen - all the things you take for granted in software you use has to be built up.

Off-the-shelf software has typically been around way longer than a custom solution and is built by a bigger team. With that, they are usually much richer in functionality at the start. As soon as you sign-up, you’ll probably have access to hundreds of features whereas with Custom software, these features are slowly built over time.

Quality

This argument can be made for either Custom Software or for Off-the-shelf Software. However, all things being equal, Off-the-shelf Software being typically built by bigger teams and tested by more people can lead to higher quality software. Some off-the-shelf software is built by the best software teams in the world and as such you might get access to some of the best software in the world.

Some other things to consider So we’re really starting to make the case for Off-the-shelf software. However, if you’re still not convinced, here are two more things to consider.

One, as we have written about before, if you’re trying to decide between the two, it’s usually a good idea to try out Off-the-shelf software first. It’s usually quite cheap and a lot of the offerings have a free trial.

Two, you should consider that it’s not necessarily all or nothing. There are a LOT of Off-the-shelf software solutions that offer integrations, APIs, and more to allow for a large amount of customization. For example, Wordpress can be considered Off-the-shelf software, but it offers a lot of customization options that allow the best of both worlds.

The right solution for the right problem So, yes, Off-the-shelf software has a lot going for it and like I said, we recommend it a lot. In fact, we use a lot of off-the-shelf software to run our business. However, it’s not always clear cut. What it comes down to is there is a place and time for each and it’s about determining whether or not your problem merits one or the other.

Even though I think most people would have considered the Off-the-shelf software option already, we thought we’d shed some light on the reasons you should choose it.

Photo Credit: Andrea Piacquadio from Pexels

Casey Li
CEO & Founder, BiteSite

Why we don’t believe in fixed term contracts

business custom software software development

BiteSite was founded in the summer in 2012 and we’ve worked with a ton of clients on a lot of projects. With that comes a good amount of experience that has given us some confidence in saying what works for us and what doesn’t.

One thing in particular that we’ve experimented with in several different ways is the way we structure our contracts and after years of developing software, we’ve come to the conclusion that we don’t believe in fixed term contracts when it comes to software development.

What do we consider ‘fixed term’?

Alright, before we get started in explaining why we don’t believe in fixed term contracts, it’s probably a good idea to get on the same page as to what is a fixed term contract and what isn’t.

While there may be many different interpretations out there, for our purposes and for the purposes of this article, we consider a fixed term contract any contract that states something along the lines of:

You will get this output for this amount of money

Now, obviously contracts are not usually written this way, but they can be boiled down to something similar. What’s more common is something like this:

You will get Feature A, Feature B, Feature C, Feature D for $10,000.00

That is probably looking more like contracts that people are used to dealing with. Now obviously, contracts are usually more fleshed out than that, but the more detailed it gets, the more “fixed” we’re talking about, and as you’ll see, the more “fixed” a contract is the worse it is.

Now, there is a small but very important change we can make to these types of contracts that we are very much in favour of. This small change removes this “fixed” aspect of it. What’s the change? Simply removing either side of the equation:

You will get unknown for $10,000.00

Or

You will get Feature A, Feature B, Feature C for an unknown amount

In either of these cases, while you are fixing either the deliverables or the budget, you are NOT fixing both. When we talk about ‘fixed term’ contracts, we are talking about situations that fix both. If you allow either to be flexible, the contract does not fall into the ‘fixed term’ category.

Types of projects

BiteSite has an interesting history in that it didn’t used to be strictly a Custom Software development company. In the past, we focused on corporate video and before that we offered graphic design and photography services. As such, we want to be very clear about our philosophy around ‘fixed term’ contracts.

When we say we don’t believe in fixed term contracts, we are strictly talking about Custom Software projects.

While our philosophy might extend to other types of projects, we have a lot of concrete reasons and evidence around Custom Software projects and thus this article deals specifically with Custom Software projects.

Developing good software

Our belief around ‘fixed term’ contracts and why we avoid them really stems from our belief in how good software is developed - or rather what we believe is the best process to develop good software. We by no means invented any of these concepts but rather followed in the footsteps of great minds.

At BiteSite, we develop software following many Agile methodologies and principles. We use a process we’ve called Scrum Express (a slightly modified version of classic Scrum) and in our many years of experience, we find following these principles works really well.

Without going too deep into these principles, one of the biggest philosophies is continually integrating feedback into your development cycle. Whatever form the feedback takes, testimonials, usage statistics, data models - it’s important to take it in and incorporate it into your product on a continuous basis.

These principles are based on the notion that no one can really predict what users will do or how they will behave, and it’s important to put out software, observe, and iterate.

We’ve seen time and time again that these principles truly work in the real world. We’ll spend a little bit of effort developing a small feature that we’re excited about and find out very quickly that no one wanted to use it. So we stop developing it. On the other hand, we’ll add a small feature that we thought was a small fix and people loved it so we poured more resources into it.

It’s all well and good to read about these principles, but we (and I’m sure so many others) have seen it in action and it’s very powerful.

So how do you plan your software product? With this in mind, it may seem impossible to have a long term plan for a software product while maintaining effective development practices and in a way - it is.

If you subscribe to the philosophy described above, you should embrace the fact that you just don’t know what the future will bring.

Don’t get me wrong, it’s good to have a plan, and it’s good to have vision, and rough idea of where you’re going, but at the same time, you have to get used to the idea that within weeks if not days, your plan could completely change - that’s what agility is all about - the ability to change.

Processes and concepts like Scrum, Continuous Integration, MVP and more all account for this and give you powerful tools to take in feedback and remain agile.

If you think you can sit in a room full of researchers, designers, engineers and plan exactly how your software will work months from now without ever putting it in the users’ hands - then you’re adopting a waterfall approach - an approach that in our opinion is less effective.

It’s a pretty logical conclusion

If you believe in these agile philosophies as much as we do, then it’s a very logical conclusion as to why fixed term contracts are bad for software development.

Fixed term contracts lay out specifics about how a piece of software will look, behave, be architected, and more - all before some serious thought, but more importantly, all before it’s put into users’ hands.

If the contracts don’t leave room for flexibility or for the potential for the plan to be completely altered, then you could be developing software in a very ineffective way and basing your decisions on what’s written on a piece of paper rather than what your users are telling you.

By leaving your contracts open ended, you allow for the agile principles to shine through.

Is that it?

Following Agile development principles is definitely the main driving factor in our belief to avoid fixed term contracts, but we’ve also seen other benefits arise from it.

When you tell a developer to “Develop Feature A for $200.00”, they will constantly be racing against the clock. They’ll constantly be thinking of ways to shave off hours, and get the minimum amount done without taking some care. Not to mention, they’ll throw out any creative ideas, or spur of the moment inspiration to make things better. The distraction of needing to finish it in the exact time or amount or less leads to uninspired output.

Further to that, if the engineers, developers, or designers have any moral conscience, they’ll probably try to minimize the amount the customer spends. That’s great, but it can also stifle good conversations and discussions that can lead to great output.

When we moved to non-fixed term contracts, we felt we concentrated less on time, and more on just developing great software.

Can’t the contractors just buffer in the expense?

Whenever we’re faced with a client who just can’t do an open ended contract, we do what we believe most companies do - buffer the cost. So even if we think it’ll take 50 hours to produce, we’ll budget in 150 hours to cover these unforeseen costs.

While this can work, there are two reasons I’m not a fan of this approach. One, I think it’s an artificial and inaccurate way to account for the cost of what’s being done. It’s almost like saying “We can’t predict what’s going to happen, so we’re just going to charge you a bunch more money.” Secondly, if it really takes 50 hours, I never liked the idea of a company paying us more than what it took. If it took us less time, the client should pay us less.

Fixed budget is not fixed term

One thing I want to stress is a point I brought up when defining ‘fixed term’. If you remove either side of the equation, it removes the ‘fixed’ aspect of it.

So while we don’t believe in fixed term contracts, we are very much a fan of fixed budget contracts.

A fixed term contract may look like this:

We’ll develop Feature A, Feature B, Feature C for $10,000.00.

A fixed budget contract sounds more like this:

We’ll aim for Feature A, Feature B, and Feature C, however things could change and we may develop other features, but let’s keep our spending to only $10,000.00 maximum.

We find customers who are not comfortable with open ended contracts are at least more comfortable with fixed budget contracts.

Trust

This all sounds well and good, but I have to remind myself that I am writing from the perspective of the Custom Software service provider - not the client. I have to remind myself that it can be really scary to sign an open-ended contract with a provider. Sure I trust myself and my team, but how can I expect you, the client to, if you’ve never dealt with us or worked with us before.

The open-ended contracts we talk about are based big time on a trusting relationship between the vendor and the client.

So how do you establish this trust?

At BiteSite, we usually recommend starting with a small fixed budget contract - not fixed term - fixed budget. In fact, we’ve taken on starter contracts as small as $500.00 to start just to see how we work together.

I’ve never been a fan of companies who say, “We won’t talk to anybody who has a budget of less than $5000.00”. We’ll go as small as you’re comfortable with. Granted, we may not get much done for $100.00 or so, but if that’s what you want to spend, you’ll get to know us and then you’ll know whether or not to trust us with more.

Going through a pilot project of sorts is a great way to establish trust and if things go well, you can continue with that trusting relationship.

So how do we structure our contracts at BiteSite?

So with all that said, how do we structure our contracts at BiteSite? Well, it’s actually quite simple. If you strip away all the fine print, the only thing we really have in our contract is our hourly rates - no feature set, no deadlines - just our rate.

Once the contract is in place, the rest is discussed outside the contract. You only want to spend $1000.00 a month? No problem, we’ll keep track of that and not go over that. You want to try to get these 5 features in by March? No problem, we’ll aim to do that. Again - there is a trust factor, but this works really well for us.

If things go south, we find these contracts work really well too. Don’t like how we’re getting along or unhappy with the progress? Simply as us to stop, and we’ll stop.

One thing I should note, occasionally our contracts will include some extra details about feature sets that were discussed. However, these details in the contract are always stated as “rough plans” or “estimates” and emphasize that we are not bound to these plans.

Value based vs time based

Some of you out there reading this might be frustrated in our use of Time-based billing vs Value-based billing. Value based billing is definitely a philosophy with its merits, but frankly, I don’t know enough about it.

What I do know is it cost X dollars per hour per employee to run my company at a comfortable pace. That’s something concrete I can gravitate towards and something that’s easy for me to plan for. As such, for the time being I decide to use time-based billing.

It can be tough

It can be tough to sell the idea of open-ended contracts, but we find that once we explain our reasons, most clients get on board and it leads to a great working relationship.

I’m not saying that these types of contracts are for everybody, and I know there are definitely organizations that are bound by their contract processes that they have no other choice but to use fixed term contracts.

That being said, the more open ended contracts we put out there, the more evidence we get that it’s the right way to go. We hope that more and more organizations embrace this idea as we believe it lines up perfectly with how good software should be developed.

Footnote:

I want to give a special shoutout to ThoughtBot. ThoughtBot is a company that we look up to and admire greatly. ThoughtBot’s open source playbook was the first place I read about this idea and seeing them write about it publicly gave us the confidence to advocate for it in our daily work.

(photo by Cytonn Photography from Pexels)

Casey Li
CEO & Founder, BiteSite

How to build your Software Startup Product

custom software software development

So you’ve decided to start a company

Alright. So you’re toying around with the idea of starting a company - specifically a software company. Perhaps you’re looking for a change in your career. Maybe you recently came across a problem that you have a great solution for. Or maybe you’ve had a ton of ideas in your head for years and now is the time to act.

Whatever the reason may be, starting a software company can be an amazing journey. You could end up building something that really changes the world.

But even though you have a great idea, you might be stuck as to how you actually get started. How do you start putting together a team? How do you build your product? How do you sell and market it? There are so many questions you have to deal with when starting a company.

While there is a lot that can be said, in this article, I hope to answer “How do you build your product?” and give your idea some legs.

Build it and they will come? Nope.

Before we get started though - I want to be very clear. Building the product is by no means the most important nor the first step you should necessarily take. It really depends on a lot of factors and each case is different. In some situations, doing market validation and research is more important first. In some cases, putting together your staff is more important.

This article is not saying you should build your product first, but rather, when you decide to proceed with that step, here are some ideas.

Developing Software

If you’re reading this article, you’ve probably got a great idea that software seems suitable for, but you might be completely lost when it comes to actually creating, building, or developing the software. However, if you’re in that state, the term “building software” itself might be confusing. What does building software actually entail? What should you understand about it? Regardless of whether you build it yourself or hire someone to build it, it’s good to understand some high level concepts that go into building software.

Product Management

When you build software, one of the most important aspects is deciding what features your product will have, the details of how they will work, and when they will be developed. This practice is known as Product Management.

Design

After you’ve decided on what features you want in your product, you might have to design your product. This can involve UI and UX design where you’re figuring out what the screens or pages will look like and how they will behave when a user uses them.

Development, Coding, Implementation

Next, you have development or coding. This is where developer (or computer scientist, or software engineer, or coder) will write code (or source code) to execute your vision.

Deployment

Deployment is the act of getting your software into the hands of your users. So for a website, it’s putting code on a server out in the internet for people to access (hosting). For an app, it’s submitting your code to the Apple App Store or Google Play.

Source Control

Source Control is using a system to literally control your source code. When you start to build software, you may have multiple people working on the code together. You’ll want good source control to track all changes, allow for parallel work and collaboration, and revert things in case something goes wrong. Having a good source control system in place will spell out success as your startup grows.

Process

Lastly, you’ll want a process to manage all these aspects of software development.

Now, it’s important to note that not ALL these aspects are necessary to start developing your product, but as you grow, you should be aware of these and more.

What are your options?

So now that you have a general idea of what developing software looks like, how do I actually go about doing it? Well, there are a couple of options.

  • Build it yourself
  • Partner with a developer
  • Hire a software developer
  • Hire a software development firm

Build it yourself

Probably the cheapest and lowest overhead way to build software for your startup is to build it yourself. If this is your startup, you could act as a product manager, designer, developer, all in one. If you happen to have a background in software development, then you’re set. Nothing is stopping you from sitting down at your computer and starting to design or code.

What if you don’t know how to code?

Well luckily, the internet is full of amazing free content to learn. A quick google search of “Website tutorial” or “App tutorial” will get you started. You might think - there’s no way I’ll catch up to seasoned developers, but that’s not quite true. I’ve met founders of startups who learned to code all themselves and build amazing products. If you’re determined, you can really do it.

Pros

  • Lowest overhead
  • Cheapest

Cons

  • Can be the slowest (especially if you have to learn coding)

Partner with a developer

If you don’t want to do the development yourself, you can find a business partner. Ideally in this case, you want to bring on someone who can wear multiple hats - someone who can do some product management, design, development and more. Sound too good to be true? It’s not. I’ve met a LOT of developers who can do all the other tasks to a workable level. Especially enough for a startup.

In these cases, a lot of the time your partner is part of the startup and you’ll have to sort out an ownership or compensation structure.

Pros

  • Best balance of overhead and return

Cons

  • Can be hard to find a good partner
  • You give up some control of your company

Hire a software developer

This is similar to partnering up with a developer, except in this case, rather than having some kind of equity agreement, you simply pay an individual to develop software for you.

Pros

  • You retain control of your company

Cons - Can be hard to find a good developer

Hire a software development firm

The last option is to hire an entire firm. Just so we’re clear, software firms or companies that are capable of software development go by many names:

  • Custom Software firm/shop
  • Digital Agency
  • Web Design and Development firm/shop
  • App Development firm/shop
  • (many more)

This option is the most expensive, but if you have a revenue source or some money that you are ok with spending, this could be fastest and could yield the best quality. When you hire a software firm, you’re getting a lot that may not be obvious. Depending on the software firm, you may get access to:

  • A team full of talented, vetted developers
  • A well-oiled process
  • Years of experience in all development aspects

Yes you’ll get your software product in the end, but you’ll also get all this along the way. The biggest issue here is cost and the high cost can also amplify the negatives if you find a bad firm. For example, BiteSite recommends a $5,000 - $10,000 starting budget to get things going. Most startups don’t have that kind of money and most are hesitant to spend that up front.

That being said, if it’s successful, you could end up with a great product, that’s properly managed, and what’s more, you’ll get exposure to what it’s like to run a successful software team which becomes very useful as you grow.

Pros

  • If you find the right firm, you’ll get a great product and great experience to carry on throughout the life of your company

Cons

  • Expensive
  • A firm by no means guarantees quality and it can be hard to find a good firm

So what should I do?

So with the 4 options, what should you choose? Unfortunately, I can’t answer that. There are honestly merits to each approach and you have to think in your situation what’s the best for you. You’ll have to see your comfort level and weigh it against the benefits you see from each option to make your choice.

Whatever you choose though - you should remember a simple philosophy when it comes to good software development: good software development is iterative.

That means keeping a philosophy of “try something, if it doesn’t work, try something else”.

Software development should never be all or nothing. Software development should be a process of constant feedback and iterating. Everyone who develops good software should believe in this, and as such, they should extend that to your decision on the approach you take.

So whatever you decide, I highly recommend finding a way to try out the approach in some small way, and telling yourself to evaluate and iterate if it’s not working. For example, if you’re building itself, try it for a few weeks and see how far you get. If you’re hiring someone, set a super small milestone to see how it goes.

However it turns out, I congratulate you on pursuing your ideas and I hope I’ve shed some light on how to build your software startup product.

(photo by luis gomes from Pexels)

Casey Li
CEO & Founder, BiteSite