Lessons learned after 20 years of developing, managing and selling a software product

I released the first version of DaDaBIK, v. 1.0 beta, in November 2001, almost 20 years ago.

It was a tool to automatically create a CRUD Web front-end for MySQL databases and it was an instant hit in the PHP community — there were very few tools of that type at the time and I think almost all of them worked by generating PHP scripts, producing code that became obsolete when database schema was changed. Instead, the idea of ​​creating a model that could adapt and synchronize to schema changes, basically mirroring the database itself, was a rather new concept.

Since that beta version, 87 versions have been released.

I went through several phases, it was released as Free Software (free as in freedom + free as gratis), then I started asking for a voluntary download contribution and finally it became a full-fledged commercial product.

It has evolved a lot, started as a simple front-end creator (DaDaBIK stands for “Dadabik is a DataBase Interfaces Kreator”) and is now a complete low-code no-code development platform.

In recent years I have been in direct contact with hundreds (perhaps thousands) of users, I have faced technical and managerial challenges.

Here is the lesson I learned during all these years, some tips and advises in random order that I would like to share not only with independent software vendors but with anyone who plans to build and distribute a (typically digital) product.

1. It’s (almost) never too late

In the period 2007–2010 I stopped working on DaDaBIK. People still used it, I spent some time replying to emails and forum posts but I haven’t written any DaDaBIK code during that time.

In 2010 I realized that DaDaBIK was the most useful thing I had created and although someone told me it was too late and that many other similar software had appeared on the market I decided to review my priorities, I started working on DaDaBIK and I launched a donation campaign to support my work.
The story speaks for itself: not only was it not too late, but a huge new trend in low-code and no-code started around 2014.

My point is: reality (and people’s needs) is often very complex and unpredictable. Problems that seem “solved” could be dealt with more efficiently; apparently “dead” technologies could be useful for new, unexpected needs. I guess most of you remember that 2010 Wired title “The Web is Dead. Long Live the Internet” :)

2. Think big since the beginning

I was already experimenting with a similar idea of ​​”automatic DB front-end” with different technologies (classic ASP + configuration file) before the birth of DaDaBIK but what became the core of DaDaBIK was written when I had to develop an application to manage contacts. I decided to write something very abstract, which would have allowed me to add new properties for a contact (e.g. a new address field) without touching my code. It turned out to be abstract enough to be used with any database, even by non-programmers, and that’s how the story of DaDaBIK began.

My point is: try to think, from the first days, about the possible evolutions of your product, lay the foundations of what your software could become in a few years. Don’t be afraid to dream big.

3. Work on your focus and productivity

I have been using the POMODORO TECHNIQUE since many years. I think it can really help and I recommend everybody to try.

I don’t use any app in particular, I just put a 20' timer (the original interval is 25’) on my phone. I try not to admit distractions: during a pomodoro, my phone is in airplane mode, the email client is closed, I tend to be disconnected from any social media platform and start working (coding, thinking about how implement something, planning, study …).

If I write code, I listen to music (electronic music without vocals, sometimes techno). If, on the other hand, I have to study, think about how to solve a challenging problem or write content, music distracts me too much and I prefer silence.
During the breaks between one pomodoro and another, I try to do something completely unrelated, for example if my guitalele is around, I play it.

If you find yourself being more productive, I think it’s best not to use the time you earn just to add more work, I think it’s important to reward yourself by spending time in some enjoyable, unrelated activities. Often I don’t, but I feel I should.

If you are having a hard time finding a solution to a conceptual problem, try focusing on something else and / or do a physical activity. Some of my best ideas were born during or after a walk, a ride with my bicycle or my Vespa.

4. Test as if you were the end user

Are you a unit testing guru? This is not enough.

You should try to replicate the entire experience of your users. I try, from time to time, to google for software similar to DaDaBIK, buy and download DaDaBIK, install it and check the manual when there is something in the process that doesn’t seem 100% clear to me.

I also use my product to create most of the applications I develop, and this will take us to the next point, Eat your own dog food.

5. Eat your own dog food

You should be the first user of your product and not just because you have to test it but because you love it. If you don’t like your product or think it’s not useful, then something is wrong.

6. Marketing and communication are important

Seems obvious, right? Perhaps not that obvious to many software developers, myself included.

Don’t think of marketing as a way to impose your product despite its value, but as a way to communicate the true value of your product to the right people.

Over the years I have received many emails starting with “I’ve been looking for this product for years!” and the reason is simple: I have never made serious investments in marketing, many potential customers do not even know that DaDaBIK exists. Almost all purchases come from organic searches, upgrades from previous versions, and word of mouth.

I can’t teach much from this point of view, not only because it’s not my field of expertise but also because, as I said, I’m probably not a good example to follow. I can only stress the importance of this, even if you are a small independent software vendor.

7. After-sale support is gold

There’s only one thing worse than not providing support: providing bad support. By bad support I mean: auto responders, chat bots, or people who don’t have the necessary knowledge. It’s worse because it’s frustrating — as a user, you not only don’t get what you need, but you feel like you’re wasting your time. This is especially true if you produce software used by other software developers (some of the DaDaBIK users are developers):

It’s sad but I think we’re used to getting bad support nowadays; especially when you are dealing with big vendors, very often you have to go through forms, chatbots, automatic filters and even when someone finally replies, you have the feeling that it is just a standard answer. If you offer premium support service, which means your users just need to send an email and they will get an answer within hours from experts, it will be very, very much appreciated. Believe me.

If you can handle most of the support yourself, that’s great. If you need to delegate, make sure the people involved know your product very well. If your customers realize they know more about your product than your help desk employees, they will start to hate it.

8. Talk to your users. LITERALLY.

I have always had a rather close relationship with DaDaBIK users, I have personally answered hundreds of emails and I think I know a few dozen by name. Is this a good thing? Well, when you personalize your product too much, you may have side effects, but in general I think it’s very important to talk to your users.

For a few years I have involved a small group of users in a private beta program. They can try the new, upcoming, major release before the official release. I arranged a short Skype call with each of them and asked what they liked and what they didn’t like about the product they were testing.

This was incredibly useful for me: not only did the users give me great advice (they were generally experienced users who have built many applications with DaDaBIK) but I was able to see and understand, without filters, some typical use cases of DaDaBIK, how DaDaBIK is used, what is the background and the (sometimes unexpected) expectations of the users: this was very useful to fine-tune the DaDaBIK roadmap!

You may think you can do this via email, forums, or any other means of written communication. Yes, you can and should create a strong written communication channel with your user, but oral, face-to-face (webcam to webcam) communication is different, richer — I’m pretty sure there are things people would not write in an email because it takes too long to formalize them, but they gladly share them in an informal chat.

Don’t assume you know who your typical user/customer is, you probably don’t.

9. Invest A LOT of time in setting up your DEV tools

The tools you use (like your code editor) can have a dramatic impact on your productivity. You should take the time to choose them and to set them up carefully. Once you have chosen your favorite tools, try to become a super expert on them, don’t waste time trying any new options available. Maybe you could check for something new periodically, like every six months or something.

I like light and fast applications. I can’t stand the “spinning wheel” :)

I just want to say a few words about two of my essential development tools:

• BBEdit. ( https://www.barebones.com/products/bbedit )
  I have been using it to write code for many years. It’s fast, light, does one thing (code editing) very well, and (almost) everything is exactly where it should be. I also use it to write generic text (if it’s just plain text), to take notes and to write content drafts which will then be formatted using other software. For general textual content I also recently tried Ulysses but eventually went back to BBEdit.
• BetterTouchTool ( https://folivora.ai )
  I can’t thank Andreas Hegenberg (the author of BetterTouchTool) enough. This tool saves me a huge amount of time. I have set up many key sequences that allow me to insert snippets of text of any kind: code snippets I use frequently, email addresses, signatures, date/time related text, git commands, and even entire email templates. I also have shortcuts that allow me to perform the actions I do most often (e.g. open a particular file, a particular application or do something on a window) without using the mouse / trackpad.
  I hate it when I have to do the same job twice and often BetterTouchTool allows me to avoid it.
  Finally, I also use the built-in clipboard manager a lot and this is also a precious time saver.

Sometimes there isn’t a standard tool for a specific job and you have to build it; for example I created my custom deployment tools and some tools that make it easier for me to test before releasing a new version.

When I talk about development tools, I’m not just referring to software, I’m also referring to hardware. Using devices that you feel comfortable with is essential for your productivity and health. I think this is a very subjective area, you should read reviews, specifications, analysis but don’t assume that the general solution is always the right one for you, always try different options until you find the right one.

After trying a lot of setups, what I’ve been using for almost 15 years is a laptop that sits exactly in front of an external display; being this external display on a high stand, I can clearly see both the monitors one under the other, but I mainly use the external one. I think this looks odd to most people, but it’s the most comfortable setup for me.

I stopped using the mouse more than 10 years ago. I only use the trackpad, not only is it faster (I don’t have to take my hands off the keyboard) but it is less tiring for me. Sometimes I have to use the mouse (for example if I need to use a desktop computer in a lab) but it feels very unnatural and causes contracture / back pain. Never underestimate the signals your body gives you, try to understand the reasons and talk to a doctor!

10. Haters are going to hate

If you achieve a certain level of success with your products, some haters will appear at some point. Hopefully you will not be insulted, but you will meet people (users, customers, potential customers) who will start criticizing your work just because that is how they behave or because they think they can benefit from it.
In my case, fortunately, it was a very small percentage. I only remember 3–4 disturbing cases. In a forum containing almost 20k posts produced by thousands of users, I only used the ban once.

When you notice that you are repeatedly receiving messages or comments containing non-constructive criticism by someone, stop responding, don’t waste an extra minute with them, every extra minute it’s time you could invest in improving your product, time you can invest taking care of customers who appreciate your work or people who provide negative (but constructive) feedback.

Over the past 20 years I have responded to an astonishing number of emails and forum posts and I have realized that I have wasted too much time replying to certain messages just because I thought it was the right thing to do; I don’t do it anymore, my time is precious, I don’t feel rude if I stop responding to people who just want to waste my time with pretentious requests.

11. Take care of legal stuff from the start

When you start a new project as a small independent software vendor, you might be tempted to postpone the legal stuff (licensing, terms of use, privacy policies, etc). There is a simple reason for this: for a software developer it’s not as fun as coding! Don’t get me wrong, of course it’s something you should delegate to a lawyer but still, your involvement is needed and you might prefer to focus on building your product. This is wrong. If your product will become popular, this is something that at some point you will regret. Take care of the legal stuff, seriously, from your very first release.

12. Explain things clearly and transparently to your users (and don’t be afraid of communicating big changes)

During the early years of DaDaBIK, people could download it for free. It was a side project and I enjoyed working on it so it was fine. The messages I received, the popularity, the articles in the magazines were rewarding enough.

At some point, however, I realized that if I wanted to seriously grow my product, I needed a different approach. DaDaBIK became commercial software and then changed its license as well. It was a big change, I explained to users what I felt and what my needs were and I was ready to face any sort of criticisms. The criticisms have actually been way less than I thought and starting from this big change the product started to constantly improve, much more than before.

Of course, I’m not saying this is the way to go for all software projects! This is just an example, the point is that sometimes you are too conservative, you are afraid of changes and you project this fear on your users / customers, who are more willing to accept changes than you think!

13. Engage your customers in the roadmap

This is quite linked to the other point (talk with your customers) but here I want to stress the fact that your customers’ opinion should have an impact on your roadmap.

I’ve tried different tools and I’m always thinking about new methods.

I had a forum dedicated to “feature requests”, where users could submit new features and comments on other users’ proposals.

For a couple of years, I involved a subset of users (the ones I thought might bring more value to discussions, according to their story) in deciding which features the next major release should contain. I used a simple shared document where users could write their own proposals, comments and vote on other users’ proposals.

During the last two years I have been using a dedicated feedback platform that allows users to describe the features they believe DaDaBIK is missing, rate and comment on other users’ suggestions.

Two aspects to consider:

• A very small (but perhaps also very noisy) subset of users consider their specific needs as general needs and assume that a particular feature will be implemented only because they need it. This happens and you need to manage it. Using dedicated tools that clearly show everyone how many upvotes each proposal has received can help.
• In my opinion, your users shouldn’t decide 100% of the roadmap. You should have your own vision of your product, what you want it to become. There are some key features, enhancements, or choices that you feel are strategic for the future of your software that don’t necessarily need to be shared with your users in advance.

14. Stop playing with all the new frameworks / tools /languages available.

Or do it if you enjoy it, but don’t pretend it’s real work.

Also, don’t assume that what people are blogging about, that appears to be a “trend” at a particular time is what software developers are actually using to produce real-world applications.

15. Understand innovation Vs. Hype

You should embrace innovation, but you should also understand the hype. I started programming when I was 8 on a Commodore Vic-20 and I have seen so many trends and cycles in the IT industry (languages, methodologies, paradigms, tools, …) that I think I can now smell the hype a mile away.

I know it’s hard to believe but many software developers, when it comes to the new and coolest technologies, are the worst fashion victims.

16. Don’t reinvent the wheel, but do it if you don’t feel comfortable with the “wheels” available

In recent years, for more and more parts of our code, writing has been delegated to pre-existing external libraries. In general it makes a lot of sense, why would I have to reinvent the wheel and build a user authentication module from scratch if there is one already available, well written and tested by thousands of people? It would be a waste of time, better focus on the most specific code for my project.

However, I often see people who are too relaxed when it comes to outsourcing an important part of their code to external modules.

Using the first library you find on GitHub for a critical part of your software just because it’s free, looks cool, and has a good number of forks is not a good idea. You should do your homework and try to understand more. When was the project launched? Are the authors constantly releasing new versions? Is there a roadmap? Do they seem interested in security? How fast do they fix security bugs? If you need support, how can you get it? If the source code is available, you should also take a look at it, don’t assume that since it’s open source, so many other people have looked at it and reviewed it.

17. Digital nomadism

During the last 13 years, I have often spent a few months each year abroad, sometimes because of academic commitments, sometimes just because I liked it. I have always carried work with me.

Over the last few years, the term digital nomadism has become popular and I think this idea has become more socially accepted; believe me, 13 years ago most of the people didn’t believe you could carry all your work with you in a laptop and that you can organize your work day without being in a office :)

I think it’s an incredible opportunity and I am grateful to live in a time where this is possible but I invite you not to see only the positive things.

1. If you google digital nomad, you’ll see pictures of people working on a beach with a MacBook. Well, let me tell you a secret: you can’t do hours of serious work under the sun (actually a friend of mine can do it, but I think he’s one of the few people in the world!) so forget about moving your office to the beach.
2. To be productive, you need routines. If you move for some weeks / months in one place, after the initial setup (see next point) you can establish routines but if you move frequently (one week here, next week there, … ) it’s difficult to do so.
3. Consider setup times. Especially if you are moving abroad, there are always setup times to consider. You have to find a house and maybe also a coworking space, you might need to do some paperwork, you need to buy a few things you could not take with you, you even need to check where are the best and closest grocery shops!

Productivity, however, is not everything. Moving from your usual home and meeting new people not only makes you grow as a person but stimulates your creativity (at least that’s what happens to me) and that’s when new ideas pops-up.

Finding your perfect mix of changes and routines is definitely something you should work on.

18. Control your ego

Sometimes, especially if you are an independent developer and are responsible for your own decisions, your ego may be driving your choices too much. You probably want to prove that you are smarter than your peers and make those decisions that allow you to do so, such as deciding to implement that particular cool (but not really useful) feature.

Listening to your ego could have some positive effects on your product, because you are motivated to improve it, but if you are looking to create a business around your software you should make those decisions that allow you to make your project sustainable in the long term.

If you listen to your ego too much, you probably won’t even be able to delegate (see next point).

19. Delegate

I think this is very hard for most of us. You always feel you are good enough and you have enough time to do everything but that’s obviously not true.

You should start delegating the activities that are furthest away from your core activity and then proceed with the closer ones. For example, if you are a one-man-band software developer you might start with administrative tasks, then marketing and SEO, then most of things that have to do with graphic design (the layout of your Website, the UI of your software, …) and finally you can delegate limited parts of your code: a module, a library or more in general everything that can be seen as a black box by the rest of your code.

20. Don’t fall in love with your IDEAS

This comes from one of the best advices I have received by my supervisor at the beginning of my Ph.D. When you start doing research, it’s easy to fall in this trap: you want to believe your hypothesis is true just because it’s a fascinating hypothesis. Hypotheses, however, need to be validated; that’s how science works.

The same trap also exists when you build a product or a service. You might assume that people need your product, your service, that your users will love that cool feature you’ve been working for weeks, but these are just guesses. When you come to know the truth don’t be afraid to admit that you were wrong if facts do not validate your assumptions.

21. Do you really need external investors?

Are you sure you are a startupper? Don’t assume you fit the typical startup path, i.e. you get money from investors and you try to grow as much as possible, as fast as possible (in some cases, regardless of your initial revenues). Perhaps you prefer (and/or your business is better suited to) a more traditional path: you start producing revenues from the very beginning, you want to grow slowly and you don’t necessary aspire to have a giant team working for you.

22. Build something you are passionate about and it will be a success: FALSE

Build something you are passionate and talented about AND useful for other people. This is, in my opinion, the necessary condition for the success of a software product.

This doesn’t mean you shouldn’t spend time following your passions! Just try to be objective in recognizing what is just a hobby and what can become a job.

23. You should seriously study database design and SQL

The relational model is pretty old but it’s very solid; relational databases and SQL are still behind most of the business applications.

In my professional career I have repeatedly seen applications based on chaotic, intricate and not-optimized databases, clearly designed by someone who didn’t have any idea about the basics of database design. This can have a huge impact on the performances of your application and if the application is complex, it can make other developers’ work more difficult. The same goes for SQL.

24. Keep your code clean and documented

There are entire books about writing clean code so I definitely can’t add much in a few lines. However, I want to stress one particular aspect: take your time when you choose names of classes, functions and variables; they have to carry information with them, even when you look at that little piece of code after many years!

You should also keep your names updated: if for example a method you wrote some time ago changes its purpose, you might be tempted to keep its name as it is; don’t do it, change the name to something that actually reflects its current purpose, even if this has an impact on various parts of your code.

Personally I prefer long names: if you use autocomplete, the typing time doesn’t get significantly worse; sure, your code won’t be very compact but it will be much more understandable when you (or someone else) read it after years (or even just after a few weeks!).

25. Improve your communication skills

I have met talented software developers with poor communication skills. You might think you don’t need such skills if you spend your working time coding. This is not true.

First of all, if you own a small business, you’ll probably need to communicate with your end users/customers. More generally, you will probably need to communicate with other software developers and anyone else who is working on your product: explaining your needs or training them choosing the right level of simplification and abstraction is important.

26. Be grateful that you are working on something you love

Nothing to explain here!

Final notes

I hope you are not thinking that I am good at ALL of these things, for some of these, I am really not! Writing this article was also a way to encourage me to improve.