Working with programmers. A simple guide for non-technical entrepreneurs.
Everything you need to know about “the secret language of programmers” before coming to a software house.
So you have this big idea for an application that will change people’s lives, allow you to expand your own business and make tons of money. But… you don’t really know much about coding and making apps. However you know exactly how you want this app to work, you just don’t know how to make a reality out of it.
Your best option is to come to people who do.
As stated by Michał Brodecki, a senior developer at Binar:Apps, around 80% of the clients coming to a software house are people just like you — with little to no knowledge about coding and developing an app.
From this short article you’ll learn basically everything you need to know before coming to a software house. At the end of this read you’ll know how the whole process of working with a software house look like and hopefully all of your angst related to working with skilled developers will vanish.
Do I need to possess any programing knowledge before coming to a software house?
In short — you don’t. Really.
Because it’s actually the programmer’s job to guide you through the entire process. As with building your startup, you will learn a lot as your product develops.
Just as you don’t have to possess any technical knowledge, you also don’t have to scan the web in search of programming jargon. Once again — it’s their job to understand your idea and translate it into a written code and a working product. Just like you go to a hairdresser — you simply tell him how you want to look (or show him some pictures) and he does his job from there. Same goes for developing an app. You need to have the idea. Figuring out the rest is up to developers.
However, if you want to acquaint yourself with some terminology, here are three words you may find helpful:
- Deploy — means “release”. When programmers are “deploying the app to the production” it means they are releasing it live, to people.
- Staging — if something is being “deployed to staging” that means it’s being deployed internally, for testing purposes
- Merge — combining additional functionalities (technically speaking — lines of code) with already existing ones. Adding small chunk of code to the big entity: the app.
Also, you don’t have to worry about being taken for totally ignorant by the programmers you work with. Even though when programmers are talking to each other it really sounds like some “secret language” you — as a client — will get explanations from them in a more “normal” fashion.
Working with a software house in practice.
It all begins with the initial meeting, where you and developer team are trying to figure out what it is exactly you need. What programmers try to determine at first, are possible pitfalls, possible issues and possible hard parts of your app.
This part is crucial for the following process, because the sooner you and the programmers spot all those possible drawbacks and hurdles, the easier the job will be later.
Sometimes a few minutes more during the initial meeting (or any of the further meetings, for that matter) would save programmers long hours of coding.
In most scenarios, you and the developer team are creating an MVP — Minimum Viable Product. The application that provides one main functionality that will earn money for you, as a client.
The first phase of creating MVP is isolating the scope of the MVP.
Your potential app cannot be all the things at the very start, even though you’d like to have all those bells and whistles and fireworks done in one take. Sorry, but… that rarely works.
That’s why isolating the scope of the MVP is so important and it’s both your and the programmers’ job to cut out all of the unnecessary parts of the idea and start simple.
What an experienced developer would tell you is that, in startup world, releasing a product as fast as possible is crucial, to get early feedback from the initial user base. And that obviously cannot be achieved if you try to cram all the functionalities in the world into the first-gen product. Imagine spending 3–4 months on developing an app. You’d burn money. You’d burn time. During that period, your business wouldn’t really grow and you wouldn’t have anything to offer to your clients.
But when you finally release the app, with all the bells and whistles it can turn out that… only one function generates revenue. And that you could have spent a small percentage of that 3–4 months period, and have an app with just one core functionality. And start to earn money sooner.
It’s all based on trust and quick communication.
One of the things that differentiate Binar::Apps from other software houses is direct communication between you — the client — and a dedicated developer team, assigned specifically to your project. Why is this so important? Because during the development period, you’d better be prepared for multiple meetings and long conversations.
As there is no middleman between you and the developer team, those meetings and getting feedback is much more efficient. You are saving time by connecting directly with developers, instead of wasting it by trying to explain everything to some middleman.
During that process, issues will come up which are not black and white. That’s why you have to put some trust in the experience of programmers working on your project. Because very often, their experience means that they’ve been through this before and they were right the last time! And the time before that… As you start working on the MVP, you’ll soon learn that sometimes it’s better to compromise at first and then expand and you should really trust your developers on that.
By trusting your programmers, you allow them to focus on core functionalities and making them more interesting and attractive. Your cooperation flourishes along the way, built on mutual trust.
What’s also very important (both on your side and on the programmers’ side) is being flexible with responding to feedback. Some companies have very strict rules as far as feedback goes — for instance: three rounds of emails and that’s it.
Such a strict attitude towards feedback is not advised. Because if you want to have your MVP done as quickly and efficiently as possible, you have to be ready to respond as quickly as possible, and give programmers feedback (in other words: permission to take further action) whenever it’s needed.
Limited number of feedback rounds would also be very risky if you try to maintain your app correctly after its release.
Almost done, but don’t celebrate just yet. Testing first.
One thing that’s far too often neglected by startup owners is proper testing of their app before its release to the public. Hence all the digital marketplaces are overflowing with products that seem unpolished at best.
To avoid that, you have to make sure that testing of your app is done properly.
At Binar:Apps the very first part of testing is done at the very beginning of the creation process. After gathering the specification, developers create automatic tests for the code. It automatically checks if something is broken. If anything new that’s being added would break the code created, for example,two months ago, you have a security measure for that. So that’s the first part of the testing process — automatic tests.
Second part of testing is done by a QA — Quality Assurance team. Those are the guys whose job is to do their best at crashing your app. They’ll do anything to spot any bugs.
Third part: the code is being released to you — so you can play around with it, check all the functionalities, perhaps provide some additional feedback.
Only after those three phases are done, you are ready to go into production and to ship the final product to the public.
Forget “perfect”. Embrace “good enough”.
When coming up with the idea for an app, what you need to remember at all times is that… no app is ever complete.
That’s why just like you shouldn’t try to cram all the functions into the MVP, you shouldn’t try to make your product perfect at the first try. Because — especially in your own eyes — it won’t ever be perfect.
Each time you take a look at your app after its release you’ll see some things that can be tweaked. Some functions that can be added. Some layout elements that can look better.
Therefore you don’t have to create a perfect and “complete” application at the first try. Because there will always be something you can improve on.
Careful with users feedback!
You may think that listening to your clients is the most important factor when it comes to improving your application. That it’s the core of sustaining the flow of money generated by an app. And sometimes it is. But sometimes — it’s not.
Let’s say that a couple of customers suggested adding some functionality, which they think would be “nice to have”. So you spend a couple of weeks and a bag of gold coins to develop this new “cool feature”. The result? Your revenue after the addition rises only slightly, if at all. Why? Because the general public don’t even notice.
On the other hand, sometimes you can spend very little time and virtually no money on developing a seemingly small function, which will generate tons of money for you, as it would change the way users interact with the app.
So always take notice of customer feedback, but be very cautious when it comes to actually incorporating it into your product.
There’s no “secret” to working with programmers. Only mutual trust.
You’ve probably noticed a recurring theme during this read. What matters most when it comes to working with a team of experienced developers when you have no technical knowledge is… trust.
That may sound bland and false to you, but it’s actually the truth.
When you first come to a software house, you need to trust that they’ll understand your intentions and your ideas.
When you’re working with developers, you need to trust that they won’t take you for totally ignorant just because you don’t code and don’t know their jargon. And don’t worry. They absolutely won’t.
When you’re creating a scope of the MVP, you need to trust that sometimes less is more and that finding a good compromise would result in better product and less spent money. The list goes on and on.
So if you are a non-technical guy, you really shouldn’t waste energy on trying to learn “the secret language of programmers”. Instead, try to learn how to trust their experience and expertise so you can make your cooperation more efficient and more beneficial for your business.
Find this article interesting? See full interview with Michał Brodecki, developer from Binar::Apps. You can also download our free ebook „How to work with a (good) software house in 8 practical steps”.
Check also Binar::TV channel for more videos about technology and business.
