What's It Like to Go From a Consulting Company to a Startup? A Developer's Perspective

Henri Kinnunen Dec 07 2015 1 AM | 8 min read

After five years of coding professionally for a consulting companies, I didn’t initially think I would even want to work for a startup. Then I saw an ad on Facebook for Fast Track, solved the challenge and got invited to lunch. After a couple of lunches with different people at, I was pretty convinced that this company would be a great place to work. Now it’s been five weeks since I joined and I wanted to write about the main differences I’ve found in working for a startup compared to a consulting company.

Before joining, I worked at a couple different Finnish consultancy companies, helping clients succeed in their software projects. Sometimes I got to work with interesting technical problems e.g. indoor wifi location tracker software, and sometimes the projects were not so interesting. Part of the nature of the business is that you don’t always get to decide what you want to do - you do what the customer pays you for.

You get to dig deep into what you’re doing

One of my personal interests is to be part of software project for several years, so I can see how the software evolves and dig deeper into the technologies used. I tried to achieve this in my previous work as well, but as a consultant you don’t get a say in whether a customer keeps buying your services or not. This happened to me more than once, as a consultant I switched projects almost every 6 months.

Jumping from project to project pretty regularly isn’t necessarily a bad thing if you prefer to do quick projects. If you value learning and want to learn a lot and fast, then startups may be your thing.

You see software evolve over time

As a consultant you don’t (usually) own the software you write, but, then again, you’re not the one who carries the possible legacy either (unless you’re specifically paid to fix legacy software). In startups, you’re the ones in charge of working with or improving legacy software. This is a good opportunity to learn and see how software evolves over time.

There was a lot of code produced during the first two years of, and not all of that code was beautiful. As a startup matures, there is almost certainly going to be legacy code from the early days of prototyping and building the first versions of the software with super limited time. You don’t choose the latest reactive UI libraries or pure functional backend technologies if those are not already familiar to you. Instead, you choose the tools you know you can get the job done with. What you built is what you have to live with. You cannot escape the legacy but instead you have to make it right.

An example of legacy is’s backend, which is pretty complex and hard to unit test, because of how its architecture evolved (not a lot of unit tests were written during its early development). Instead of trying to make it easier to write unit tests, the team decided to build an extensive set of API tests as a safety net. Our backend communicates with Facebook’s API so it makes sense that we test what goes out of our application and what comes in. Those API tests are a good way to deal with testing our backend, but we still lack an easy way to write even more and better tests. The easier the test writing is, the more tests there will be. This is one the reasons why we’re planning on rewriting some of our application logic; so we can create better architecture and build an even more scalable and robust system.

As a consultant you may have the option of saying “unfortunately we can’t help you” if you don’t feel like that you want to work on legacy stuff. In a startup, you don’t have this choice. If you built it, you fix it. Personally I think this is one of the things you can learn the most from when working at a startup.

You get to design the process

I was already pretty familiar with Scrum and Kanban methods before joining Smartly because they were very common in consulting projects. However, usually customers’ software development processes were not good enough, so they needed attention especially at the beginning of projects.

When I joined I was surprised by how good things were in this regard. There were Kanban boards in place, the team had daily meetings and weekly demos. They had electronic story tracking and people were generally very aware of how to build software the right way.

Not only that, but our team is constantly questioning our process. For example, we realized that daily meetings with the whole development team we’re not playing out well. We decided to split them up so that each feature team holds their own stand-up meeting, followed by a kind of scrum-of-scrums standup meeting with the whole development team. The latest version of this is that the scrum-of-scrums style meetings are only held every other day, and we’ll continue to iterate to improve our process if we need to.

For me, another process improvement is not having to keep detailed bookkeeping of the hours you bill from the client, which was one of the downsides of consulting. This may not sound very bad at first, but depending on how much detail the customer wants, bookkeeping can take up 30 minutes each week. That’s two hours per month, which suddenly sounds like a lot! At Smartly, we don’t track hours and everyone is responsible for taking care of themselves and not working too much.

At I’ve gotten to work with talented and bright people who are all professionals in their own fields. Working with the best people allows you to learn faster and it also makes it easier to build processes that support efficient software development. As a consultant you end up working with whoever your client is and you need to handle it - they may be brilliant, but sometimes they’re not.

You get a say in what you work on’s development team is split into smaller feature teams with two to five developer each. Electronic ticket tracking for stories gives everyone an overview of the bigger picture. The idea is that developers get to have a say in what they want to work on. Feature teams are not silos and they are not sealed. People inside teams can change depending on what needs to be done and what people want to do. This is really nice, since usually if you work for you’re doing a consulting project, there is a fixed set of tasks that the client wants to be done. You may suggest what you want to do, but depending on the client, that may or may not happen. At, we have a lot of things that need to be done and, as a developer, you can choose what you want to learn and then work on that. You don’t need to ask for permission from the client to do something, you just do it. You may need to ask for forgiveness afterwards if things didn’t play out well, but you and your team have learned so much in the process!

Frequent deployments enable constant feedback

One of the things I personally really value in a project is minimizing the feedback loop. I’ve worked in projects where it can take months (no kidding!) to see your code live and get real customer feedback. Delays like this can be frustrating because you may end up forgetting why something was done, making it harder to fix. The best scenario is to get instant feedback and this is what we try to achieve at

We have an almost instant release and deployment process in place. When you finish a feature and find someone to review it, you tell Hubot to deploy your feature. If tests pass and everything goes well, your code gets deployed to production almost instantly. This way we can deploy to production multiple times a day and start getting real customer feedback. It makes me as a developer happy to deliver stuff.

We like to keep our developers close to our customers, so we all do support shift every now and then to get firsthand information on how things are going. This is an awesome way to see how our customers use the software. And what would be better way to get feedback than having your customer tell you that she loves the new feature that you deployed a couple of days ago!

We’re looking for more awesome people to join our ranks, so check out our open positions or drop me a line! You can find me also on Twitter.

   Creative Testing Playbook Finding the Winning Creative Concepts CHECK IT NOW
Henri Kinnunen

Read Next