andrea_sdl

(Italian here) AFAIK Italy implemented the logic to be valid for 9 months, which wasn't ideal and it shows its limit in situations like this since we don't have a short expiry date.

Dunno if in the end they also put in place some kind of blacklisting for leaked certificates

I'm a big fan of bitwarden, it's my first advice to everyone, but to be honest it's nowhere near the refinement of 1Password which I also use)

It often lacks polishing and features, I truly do hope that with the many users migrating they'll put some extra work to make it first class

I feel the same way and being a 'Generalist' mostly because of my ability to adapt any environment is both amazing and terrible.

The terrible part is mostly because I got too many roles and zero help to grow (I'm often the icebreaker of a tech or role), which lead me to myself doing the actual criticism to ensure I'm doing my best.

On the other hand this kind of continuous self-doubt is stressing, so reading a comment like yours is a relief :)

Thanks for writing it :)

I agree, history is not important, but using phone/mail/chat always implies some kind of "requiement of attention" and given the many groups I need to update I wanted to give them more time instead of reducing it.

Right now scheduling calls diminishes time on the people you involve, so if it's a simple update why not give them the choice?

It might be a result of our former structure that leads to this issue I am experiencing (or it might be an issue I only have :) )

Ok, so, as both a developer and owner of a company that built a physical product (in the Cosmetic field, so no tech stack :D ) I'd say that, at least for me it all starts with scratching my own itch.

Create it for you, solve your problems, chances are you are among a group of people that share the same issues and the work will be "where do this people group together?"

Creating a company in a cosmetic field was challenging, but I do believe it's something feasable for everyone as long as you accept the fact that you must delegate part of the work.

I still think that this might be true for the dev field, so yeah, as many other pointed out: Build a decent MVP that solve a problem, share it with the people who care.

Obviously, for me, turning into a product means "making some money", otherwise you're simply testing. So, the process to get from "I have an idea" to "I have a product" might vary a lot.

I started saying "Scratch your own itch" because if you are not solving something you care about and you are infatuated by an idea, doing the market research, finding what the ideal customer really wants is hard. Instead, if you are the first customer of your product and use it daily it's much easier to find pitfalls, problems, defects and so on.

From there, a good advice I always found is trying to sell it to the circle of people you know even before selling online. If none of them buy the product (note the word "Buy". don't give it away for free) there's a good chance something is off. Yes, they might not be your target user, but I would bet that you should at least have a friend that shares part of your interests.

As for how to choose ideas: We have limited time, so I invest in the one with the higher probability of success and leave the others in a list. What happens is that, from time to time (rarely but not so much), I'll see someone else came up and made money with a similar idea. I'll bite my finger, smile, and move on :D Afterall what counts is not the idea alone, it's the execution. That will -always- make the difference.

I agree but I'll tell you (as an apple fan in the ecosystem) that sometimes this kind of "let's abandon the old things" has some drawbacks. For example, the changes in the https behaviour and support for the websites, made an old mac useless because safari didn't support the new TLS versions and there weren't any decent alternative for an old system like that (we're talking about a 2004 mac if I recall correctly, intel 32bit, so yeah, I know it's old in many ways).

The only solutions was to install linux and it worked.

So, even though I'm fully committed to the ecosystem and I love each and every apple product I still do think that having to trash a machine after 10 years isn't so good considering that those machines are usually still capable to work daily.

Not tech related: The power of vulnerability by Brenè Brown (audiobook/course). Worth every single penny. You can get a glimpse of what's it about on the netflix documentary about her.

Adyen has also high requirements for companies in terms of volumes, so it's an alternative but available only to a subset of companies

There are many things that might influence the result and therefore your decision.

I once worked for a product in the SaaS business and what helped us is understanding "where are our customers". So, where are _your_ customers? How do they come to your product, how do they discover your product? After having this answer we focused on improving that conversion rate (for us it was all about being first on google and having a high-converting landing page, but in your case forums might be a better place to look at. It all depends on the target customer)

Also, one issue I've often encountered is that knowing the customer and selling to the customer might be very different things. Did you only sell online? One great piece of advice is try to sell the product IRL and record the audio. After many failed and successfull attempts you'll have recordings of _what works_ and what doesn't work for the kind of customer. That information will be useful to convey the benefits into your landing page / homepage.

Back to your question: How much growth should you expect? It is a generic question. How many people are impacted by your product? How many have that specific itch to be scratched? How fast can you get to them? How good is your product at scratching the itch? The (partial) sum of these questions might lead to the answer. If you have many people impacted by your product, if the product scratch a big itch and you can reach all the people at the same time, chances are you're going to grow fast.

If you grow slow, is it bad? It might be bad if you're asking 5$/month for an extra. If it is 100$/month maybe a slow growth might make sense.

In the end, if I were in your shoes, I'll wait a year to decide if it's time to give up, but at the same time I'll set some monthly checks to see how growth is going, what are the feedbacks and how the community is reacting and test each month a different way to market the product. A good book on this is "Traction" by Gabriel Weinberg

PS I also run a side business creating cosmetic products (not saas) and my growth has been relatively slow. The product (in my case) fixes a big itche and had no competitors. Reason for that is that achieving a stable efficient result is quite hard, but we somehow made it (bootrapped obviously). In our case slow growth was a good thing because it allowed us to fix the issues in the product before being too much known in the public.

We did it many years (11) ago for a B2C Product, around 200K users (free, 5k paid). We both had a common Postgres where we stored generic info and the customer database in Derby (product was in java).

At the time we weren't that much experiences so we also implemented migrations (whereas today I would have chosen flyway or something similar).

Customer data was text based so we didn't have that many custom fields but at the sime time we had many migrations during the years.

So, would we still do it? Yes and no. It was amazing because it let us isolate each user. With Filesystem backups we could restore just in time the data from each user without having to reset the whole database and with little to know system knowledge.

At the same time it restricted our choices when improving the product. If we had to do a whole refactor of the project we always thought "How do I migrate all the users together?" We had to think about versioning, upgrade in different times and so on.

From a tech standpoint it wasn't much of a problem, but it burdened the project a little bit. Bigger refactorings are harder and you need much more depth when you think about big new features.

I still think it was a nice solution, but this solution came also because we didn't knew a thing about partitioning in databases and we weren't expert in clustering. All in all it allowed us to create a product sustaining a decent customer base with low knowledge for that time.

With today technology I'd test if we can do it other ways.

Well, it's quite clear that JS is seeing a transformation at higher speeds, but a the same time I feel like the backend offerinngs are now more diverse and they do, too, evolve.

Spring in java is pushing somewhat on functional programming and lambdas are now another way to work in java, which means you can achieve a some kind of real func programming.

We have some beautiful newcomers like Elixir which are trying to fill a gab, so yeah: I think the JS world does seem like it's going faster (and it sure does until it reaches a "mature" state), but at the same time we have great evolutions across all the stacks.

Obviously not everything changes, some things stay the same, that's because we're looking at some mature technology and not the bleeding edge, but if we look at the outliers, I think you could easily pick at least an innovator around each backend language.