Bubbles of tribes and social media

Hello, Konstantin here again!

Today I want to tell you about bubbles.

We are social creatures. As soon as we figure out some interesting topic, we try to stick with a group of people, also interested in the same thing.

We join Facebook groups, follow people on Twitter, join Telegram chats and communities on the web.

I did this every time I got interested in some topic.
Here is the list of such topics, that I got interested in over last several years:
1. (Russian) Python developers groups
2. Russian e-commerce
3. Worldwide drop shipping
4. Solo makers

The reason we join these communities is simple: we want to stick with like-minded individuals, learn from them and be like the most successful of members from those groups.

Unfortunately, I’ve observed that amount of new information, new topics and new people in every niche get exhausted.
Topics are repeated over and over again. Most exciting people stop posting interesting stuff because they get busy (probably tired of becoming successful and having no more time to contribute to the community).
Niche becomes too popular, and new people come.
A lot of new people abuse growing communities by posting self-promoting links.
Some try to make up for failures in their real lives, and their behaviour ruins the healthy and supportive atmosphere of the community. Such conduct manifests in being gross, cynical or elevating value and exposure of their persona in each conversation.

What I’ve seen in those types of groups I’ve mentioned earlier.

1. (Russian) Python developers groups.
Developers mindset often leads to hate against any paid software product.
Additionally, a large amount of envy to the success (primarily financial) of other members of the community makes it the worst place to ask for feedback or help of any kind.
Developers love to brag about everything: tools they learned, events they attended, computers, even fonts they are using in their terminal.
Pouring tonnes of crap to others’ creations, opinion or apps choices. Constant race of fears of not knowing every possible feature of the language which in turn only increases the level of stress.
Non-stop holy wars between lovers and haters of tools like apps, modules. Django vs flask. Digital ocean vs AWS. iPhone vs Android.
In the end, there is only one group of people who like such niche communities: recruiters, who seek a candidate for a specific job.
I must add, though, that worldwide python communities are way more kind, supportive and welcoming. But some traits are still there in every software developers’ community.

2. Russian e-commerce.
I have joined all possible groups of this niche to figure out common struggles among e-commerce companies.
I asked questions, advised based on my experience in software developer and offered various tools that can help people.
As many people say: start from giving value and help others, then ask for something. I did my best.
In the end, truth bluntly hit me in the face. Russian e-commerce people hate developers, hate web service owners like the human body hates sicknesses. Developers cost a lot, so they seek to hire freelancers for an absurd wage. Web services are perceived as abuse for e-commerce companies, which drain money, and their services have to be free. Because it is all automated and does not involve human labour, making web services business model too high margin, compared to the e-commerce business. And this is envy again, and they don’t take into account how much time and effort goes into developing, iterating over the product features and implementation. They compare only the result โ€“ e-commerce has low margins, web services “do nothing, their servers do the job.”
Then I sought ways how they try to serve their customers better, do they advise on this matter. It seemed to me that they are hiding their bright ideas from competitors because nobody talked about it in groups. After some extensive digging, I realised that there are merely no attempts to make their customer service better.
They seek ways to resell more without added value but increased margins. How to sell and not provide a service, to avoid refunds, to not hear customers’ complaints.
They even discuss how to make customers pay for every interaction with a site because it consumes the resources of their servers!
There was very little I was able to learn from this niche.
I left all groups and communities after several months of repeated topics:
– Excel driven automation.
– Everyday question (which CMS/CRM to use).
– Complaints, a lot of them. (Delivery services, web services, etc.).
– Legal advice on how to avoid being sued by customers for delivering broken products or breaking some expectations from their service.

Goodbye, to never see you again, Russian E-commerce.

3. Worldwide drop shipping with Shopify.
Here there is not much to tell. What part of the catalogue of AliExpress is best to resell. How not to look like reseller from AliExpress.

4. Solo makers.
Problem with solo makers communities is the most problematic to describe to make things fair.

Let’s start from the beginning and the reason why such communities were created.

First of all, they were made to help people build their apps, launch their projects, assist each other and motivate to keep going when things get tough.

It is true that many people help others to overcome obstacles and motivate and support each other.

I got help from many other indie makers, that tested my apps, provided valuable feedback, gave great advice. Thank you, people! I am forever grateful for your help and kind words!

I must say though, the problem with these communities lies in their growth and popularity, that indie maker movement gains day by day.

As more and more indie makers come to these communities, they start to abuse all available channels to promote what they have created.

They ask for upvotes on ProductHunt. They share their apps in a way that instead of asking for feedback they only throw the link to the chat or forum without any meaningful description and never show up again to see what people said about it.

Interesting topics get exhausted, and instead of insights and interesting ideas all niche chats end up limited to a conversation in the following form:

Maker1 joins the chat.
Maker1: Hello, happy to be here. I made an app. here is a link to product hunt go check it out!
Maker[2-N]: Awesome! Cool! Super! Upvoted

That’s about it. Link posted, one of several typical phrases posted in response.

I think it is possible to replace a large part of such communities with several bots and nobody will feel the difference.

I understand however that people have limited time and canโ€™t check out every single app their peers created and provide meaningful feedback, but the situation described takes from the value of those communities.

With enough effort, it is still possible to find links to valuable resources there. People still produce great apps that others can benefit from by using it.
People still help each other, they beta test apps, they upvote on ProductHunt, they still support each other.

With Makers communities, I found one problem that was hard to describe at first. It was a feeling.

At first, I was trying not to miss a single post on IndieHackers, in Telegram Channel Solo Founders and other similar ones.

I took part in conversations, tests apps, read landing pages, checked sites on all devices I had and subscribed to newsletters.

In return, I got help from others, and again, thanks a bunch to those people!

But a week ago I found myself avoiding these communities. I felt very little motivation for opening any makers chat or community.

So I tried to figure out what the problem was.

I found these points to be the ones I became tired of:
– everything revolves around publishing on ProductHunt
– everything was about bringing a product in front of the eyes other makers, not their target audience and potential customers.
– It became a club where people did stuff to show other makers what they can do. Amount of success is measured solely by ProductHunt upvotes.

To be entirely fair, I must admit that stories I have been reading on Indiehackers.com were inspirational. I don’t open those interviews anymore. I think it is because I am already motivated and inspired. I already know that it is time to ship. Time to figure out and iterate over that precious idea. I have done enough reading.

After all those examples let’s get back to bubbles in general.

They are very inspirational and exciting when you first dive into the place where like-minded people hang out.
Being in a niche community gives you the feeling that you are on the right track.

I have come to learn from experience though, that it is easy to accept a common behaviour and mindset blindly following what others do.

Such blind faith can limit what you can achieve.

If a community has thought leaders that are bragging about some approach that worked for them, it is possible that you start believing that it is the best way to do things. You begin to follow this survivorship bias.
But it may not work for you for many reasons. Also what they say can be only part of the truth that they decided to share.

Also, keep in mind that sometimes thought-leaders in a niche can be selling something around a lifestyle they are talking about. Be it, digital nomads, dropshipping on Shopify, SaaS founder, it can be anything.

When you join a community, make an effort and see who is the admin or the most vocal person in this community and what are they doing for a living. Such research can give you an idea of how to filter what they write.

To finalise this post, I’d like to say that it is good to feel like a part of some tribe. It is entirely natural for humans.

But be careful blindly consuming what the tribe says.
Use your brain to figure out what’s best for you, what works for your product and your circumstances.

Help others, listen to your peers, but decide for yourself.

Good luck!

What if IT engineers were on the road

Coder, programmer, developer, team leader if they were on the road.

Coder. A passenger on a bus. It is easy for him/her to complain about how car drivers are driving, what mistakes they make. Because coder knows everything. He is sitting on a bus and observes everyone. He/she is the smartest one. When coder is not on a bus he is a pedestrian. When he needs to cross the road, he is doing it right away, because he is right and all drivers around should stop immediately to let him cross the road.

Programmer. A driver of a small and agile car. It can accelerate, manoeuvre, and stop very fast. Programmers have more thing to worry about. Other cars, pedestrians, etc. Loves to complain about buses that only there to interrupt his awesome ride with its stops and all those passengers who also happen to be pedestrians crossing the road. Truck drivers are also annoying programmers because they are slow and big and also only there to be annoying our precious programmer.

Developer. A truck driver. Big truck, that has crazy inertia, limited view angle, a lot of blind spots. Has to predict the actions of other drivers and pedestrians. If pedestrian starts crossing the road far away, truck driver should slow down already, keep a distance from a sedan ahead of him. Because sedan would break very quickly in front of a pedestrian. The truck can’t stop that fast. A truck driver cannot afford to chat on the phone like all those above usually do.

Team leader. A bus driver. Not only his bus is super fat and slow and hard to navigate with all inertia. Like a truck driver, he needs to pay attention to other cars and pedestrians. He also has several dozens of coders aboard and his driving affects them as well. While they sit there and complain.



How to approach writing requirements

My name is Konstantin.
Most of my professional life I was in charge of making new apps happen related to web development:
– Make a new website
– Make a new app
– Make a new feature for an app
– Make something that will solve the problem of a client.
In the beginning, my inner developer wanted to jump straight to creating a new piece of software and ask questions later.

Over time I’ve learned that there are requirements for a piece of software and it is a good idea to collect them first and write the app according to those requirements.

At some point, I’ve figured out that collected requirements often don’t reflect the real needs of users, even if you ask them directly.

Continue reading “How to approach writing requirements”

Month of hard work in silence

It’s been a while since I’ve posted an update on our project.
I was very busy with day job and helping my wife with kids.

What has changed since I wrote the previous post?

First of all, I’ve used a free account on Product Hunt Ship to make a landing page.

Here it is: http://withmetrics.com

About Product Hunt Ship: it is a good product for the initial start when you have no time to write a copy.
In my opinion a bit expensive in a paid version, but I haven’t explored it yet.

During the last month, we had a lot of work to do with WithMetrics.

Currently, the app is running in closed beta for several e-commerce sites.

It was running an old version of the app, with MVPish interface, old functionality, old performance and so on. But it was working for a long time and did a great job for those who happened to be on our shortlist of beta-testers, bringing the value.

I have decided to develop a new version based on an existing codebase.

Old codebase was pure Django project with server rendered templates, with celery, Django REST Framework and couple less known libraries.

First thing I have changed was a custom user model. We wanted to get rid of usernames and make customers use their email instead.

I have replaced the user model and moved on with building the interface and improving internals of the project.

After some time and we have noticed that our new codebase outperforms our old one, that was running in production. Plus we have implemented some new features that wanted to get tested on real data.

Here our problems began.

The root of all problems was that changing the user model in Django on an existing project is super complicated and has no single solution and requires a lot of manual work.

What I have done: I have created another branch, based on production code, changed user model, recreated all users with the same IDs and used dumpdata/loaddata built-in Django commands to import apps data from production.

Then manually applied changes and recreated migrations.

I was lucky not to have any Content Types linking to User model because this causes more work to update relations.

The nerd part is over.

Some ideas from the product part.

We’ve done some research and figured out that the most valuable step for the worldwide market would be Shopify Integration. From what I have seen Shopify stores are about 80% of customers of other e-commerce related services.

So Shopify integration will be our priority when preparing the English version of our product.

With lack of time, this is it for today’s update.

I want you, readers, to subscribe on our landing page to receive updates and get notified when we are ready to launch.

To do this:
– Go to http://withmetrics.com
– put your email and click subscribe.
– optionally you will receive a confirmation email where you have to click a link to confirm your subscription.

I promise more interesting stuff and hope to post it more often!

Writing documentation for yourself

It sounds weird to write documentation for yourself, right?


Imagine a project you are working on. You finished it, deployed and haven’t touched it for few months.

Now, after this long period of time, you decided to get back to it, make some improvements or fixes, update some packages.

Continue reading “Writing documentation for yourself”

What it takes to build a side project?

If are talking about building a side project it means that by definition we don’t spend fulltime building it.

If you have a day job you are probably spending most of your time thinking how to solve issues and complete tasks related to that job.

It is very costly to switch between trying to do both your day job and your side project during the day because switching between two projects that require creativity is very costly for your brain.
Continue reading “What it takes to build a side project?”

What e-commerce focused SaaS are we actually building?

What our SaaS is about?

Let me start uncovering this secret ๐Ÿ˜

To describe our web app I’ll start from some distant point to give readers some context to better understand the purpose of the service.

One of the most important things for e-commerce companies is CPO, which stands for Cost per Order. This term means, how much money does company spend to make a customer put an order.

There is no secret, that acquiring new customers is very expensive.

One way to reduce the marketing cost per order is to find cheaper ways to advertise.
Continue reading “What e-commerce focused SaaS are we actually building?”