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

WebUSB - Bridge between USB devices and web browsers

14
.
11
.
2023
Burak Aybar
Ruby on Rails
Frontend
Backend
Tutorial

Visuality comes to town - this time it's Poznań

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

CSS Modules in Rails

14
.
11
.
2023
Adam Król
Ruby on Rails
Tutorial
Backend
Frontend

How to choose a software house.

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Business
Visuality

JSON API versus the NIH syndrome

14
.
11
.
2023
Nadia Miętkiewicz
Backend
Frontend
Tutorial

From Idea to Concept

02
.
10
.
2024
Michał Krochecki
Ruby on Rails
Business
Startups

Styling React Components

14
.
11
.
2023
Umit Naimian
Ruby on Rails
Frontend
Tutorial

How good design can help your business grow

14
.
11
.
2023
Lukasz Jackiewicz
Design
Business
Marketing

TODO not. Do, or do not.

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Software

CS Lessons #003: Density map in three ways

14
.
11
.
2023
Michał Młoźniak
Ruby
Backend
Tutorial
Software

Clean code for the win

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Backend
Frontend
Business

Crowd-operated Christmas Lights

14
.
11
.
2023
Nadia Miętkiewicz
Ruby on Rails
Backend

How to startup and be mature about it

14
.
11
.
2023
Rafał Maliszewski
Ruby on Rails
Startups
Business

A journey of a thousand miles begins with workshops

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

CS Lessons #002: Data structures

14
.
11
.
2023
Michał Młoźniak
Ruby
Software

Summary of Phoenix workshop at Visuality

14
.
11
.
2023
Karol Słuszniak
Ruby on Rails
Visuality
Backend

CS Lessons #000: Introduction and motivation

14
.
11
.
2023
Michał Młoźniak
Ruby
Software

CS Lessons #001: Working with binary files

14
.
11
.
2023
Michał Młoźniak
Ruby
Software

Working with 40-minute intervals

14
.
11
.
2023
Sakir Temel
Software
HR

THE MATURE TECH STARTUP DILEMMA: WHAT'S NEXT

14
.
11
.
2023
Susanna Romantsova
Startups

Win MVP workshop!

14
.
11
.
2023
Susanna Romantsova
Startups

FINTECH WEEK IN OSLO: WHATs & WHYs

14
.
11
.
2023
Susanna Romantsova
Conferences

MY FIRST MONTH AT VISUALITY

14
.
11
.
2023
Susanna Romantsova
Visuality
HR

NASA 1st global hackaton in Poland? Visuality Created it!

14
.
11
.
2023
Rafał Maliszewski
Ruby on Rails

Berlin StartupCamp 2016 summary

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