14
.
11
.
2023
24
.
04
.
2018
Ruby on Rails
Business
Visuality

How to choose a software house.

Michał Piórkowski
Founder

Visuality was created about 9 years ago. Since then I've made a lot of new friends who, once in a while, ask me to help them find a good development house. Some of them do not know or remember that I own one, but that is not the point. The main point is that not always I have the feeling that Visuality would be the right fit for them. Seems strange, right? Why wouldn't I use this opportunity to sell? Well... There are few important questions you will have to ask yourself, before you decide which company will take care of your awesome project.

Stage

So the first question you should ask yourself is which stage are you at and what you want to achieve. I have seen a lot of people trying to do a MVP and looking for a large dev house when they could easily try to prove their concept by creating a simple WordPress page. I am not suggesting using Lean Startup Methodology by all means, but I strongly encourage you to at least consider it - sometimes you do need to spend a single dollar to know if you have a good idea.

People

So let's say you do need a software house. A very important factor, when considering different options, is the team. After making sure that given company is in your budget range you should definitely meet the team. Not only the founders or sales manager but also the project manager that will be responsible for your product. Remember, that the team working on your project will become your everyday companion for the following years. If there is no energy, no trust and no chemistry - look further. You must feel comfortable around those people and you need to be certain that those are the people to do the task. Otherwise you will be just wasting your money and time.

Time

And that brings us to another important factor. Most of you think of time as a deadline date. It is good, you should keep it in mind (rarely you will need a team that is available in a year from today) but it is not actually what I wanted to tell you. My goal is to stress the importance of having a lot of time as a product-owner. If you are planning a big project or are already running one and you know that you just have an hour a week to maintain a relationship with software house - don't bother. You will waste your precious hours and a lot of money. Working on any kind of software will require a lot of time and energy from the owner or the person designated as the product/project manager on the clients' side. There a lot of decisions to be made and many meetings to attend. Be prepared to think about your project every day - only then it will make sense. And as for the deadline - the more you think about your project, the more ideas you have. Some of them will need to be implemented so it is good to be realistic about the deadline. You will need to constantly control the number of functionalities in the first version or another iteration so that your deploy date will stay more or less the same. And there is another important thing - do not try to fit everything in your product - try to release next versions ofter so you know if it is the right thing for your market.

If you are not embarrassed by the first version of your product, you’ve launched too late.

Reid Hoffmam, the founder of LinkedIn

Price

So I went a bit off the topic - but I needed to stress that out. Let’s come back to earth and think about the money - because this resource is probably limited:) Before you start talking to the companies think of the budget and do not try to hide it. If you feel that revealing the budget might tempt the company to raise prices - do not bother to talk to them. You have to trust them, remember? Besides, most of good software houses work on time & material basis and their prices per hour/day/month are well known. And there is another thing - I know it is not always possible, but please do not make a choice based solely on price - nothing good will come out of it at the end.

Methodology

Another crucial thing to know before you make your decision is which methodology you should choose. I would strongly suggest AGILE as it is the perfect fit for most startups and ongoing projects. You can easily control the scope of work. You can change the spec during the process without having to wait until the previously planned work is delivered. Moreover, you can easily create a clickable version within the first couple of sprints and see it grows week by week. Waterfall or any other heavy methodology is a good fit for corporate clients building a huge software - but as long as you are not another corporation - try to work as close to the product as you can and be AGILE on every stage.

Geography

The times where you had to work with a company from the same city or country are over - but try to find a team that has experience in working remotely.

Social proof

Last but not least - ask for references. See who the company worked for and maybe ask around - you might learn something useful. We strongly recommend checking out clutch.co - not only because we were selected as leaders of industry few times, but also because there are a lot of companies to choose from - and remember, not every company will be a good cultural fit for you.

To sum up: Concentrate on the people - at the end they will be responsible for your project. Find a team with passion for their work and excitement for your project. Try to keep in mind that proactive and crafty team can be a better fit than just experienced one as creating software is also about having fun with the people you work with!

Michał Piórkowski
Founder

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

14
.
11
.
2023
Michał Łęcicki
Ruby
Conferences

Easy introduction to Connection Pool in ruby

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend