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

Safe navigation operator '&.' vs '.try' in Rails

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

What does the ||= operator actually mean in Ruby?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

How to design an entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Should I use instance variables in Rails views?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Frontend
Backend
Tutorial

Data Quality in Ruby on Rails

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

We started using Event Storming. Here’s why!

14
.
11
.
2023
Mariusz Kozieł
Event Storming
Visuality

First Miłośnicy Ruby Warsaw Meetup

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

Should I use Action Filters?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

Value Object - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Introduction to DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Safe data migrations in Rails

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

I love dev, and so do we!

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

Updated guide to recruitment process at Visuality

14
.
11
.
2023
Michał Łęcicki
Visuality
HR

Visuality Academy for wannabe Junior Engineers

14
.
11
.
2023
Michał Piórkowski
HR
Visuality

How to approach funding as an MVP

14
.
11
.
2023
Michał Piórkowski
Business
Startups

Visuality 13th birthday

14
.
11
.
2023
Michał Piórkowski
HR
Visuality

How To Receive Emails With a Rails App in 2021

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

Project Quality in IT - How to Make Sure You Will Get What You Want?

02
.
10
.
2024
Wiktor De Witte
Ruby on Rails
Project Management
Business

5 Trends in HR Tech For 2021

14
.
11
.
2023
Maciej Zdunek
Business
Project Management