#1001-projects

January 11, 2022 · 5 min read

One Thousand and One Projects

How to ship consistently, have fun and make a buck for a living? Solve problems for others consistently by using your strengths.

Photo by suzukii xingfu from Pexels Photo by suzukii xingfu from Pexels

As an exploration experiment, I will try to ship as many projects as possible. Think of 1001 as a metaphor, not as an exact number. 1001 experiments or 1001 tries, you name it.

A project

At this moment, the definition of the project for me is an accomplished thing that I can share with others. It can be a SaaS, an essay, an API project, a blog post, a mobile app, an open-source library, an HTML template, etc.

My skills

I am not good at design and marketing, but I am decent at server-side development. API is an excellent kind of project for me because I can:

  • build an API project quickly;
  • deliver good performance;
  • create an optimized infrastructure to make them cheap;
  • save money and time for customers and understand what an impact I have.

But I want to acquire new skills like creating decent UI, coding on the client-side, projects promotion, AI, etc.

So, I assume that I can improve my skills in different areas by practicing constant shipping.

One thousand and one

There is no guarantee that I can make a successful living from one, then or even hundreds of projects:

  • the world is random;
  • the luck is rare;
  • and hard work does not guarantee anything.

I do not know how to solve described assumptions, but doing nothing won’t help definitely. I can only embrace the randomness and unpredictability of our world.

That’s why even if I fail — I want to have fun. And I do not know any other way to have fun rather than create something consistently.

Starting from scratch

So, the goal is to ship projects consistently. But I do not have anything to start from. I do not have any shipping system, schedule, or tools.

It will take time to build a “project shipping system” from scratch:

  • reusable design templates;
  • scalable marketing strategy and tactics;
  • reusable frameworks and automation tools;
  • deployment system.

I do not care if, in the beginning, it sucks because I understand that each new solved problem and the shipped project will improve the tools and other projects.

If I use the same but adapted UI template for all projects, fixing it one project will fix it in other projects.

Scope

I am not going to build large projects. I will try to keep them as tiny as possible until they bring value or fun.

Even API projects might vary widely. Imagine API for analyzing text and producing semantic structures from this text or detecting objects on the images. These kinds of APIs can be large projects by themselves.

So, the goal is to start small.

In public

I do not think it is required, but I find myself loving to share what I do in the last time. Why?

Because it requires me to think of what I do from different sides, but in addition to that, if somebody reads what I post, they can give me a piece of valuable advice or share an insight.

How far can I go with building in public?

For now, I do not know, but it can be from open-sourcing all the code and everything I do to just monthly updates. I will experiment on this topic.

I will tweet and write long posts at my blog, Indie Hackers community, or Reddit. I need to try and understand what works best for me.

Marketing strategy

Promoting hundreds of projects manually is impossible, and I need a scalable strategy.

One of the strategies I see is to use SEO. It is hard to bootstrap, but it will beat every other marketing strategy when it catches.

I can solve customer problems by providing the best content in a niche. If the content is not enough, a customer can buy my product.

I will evaluate if I can outsource SEO for some projects and outsource the marketing at all. The time will show.

Amortizing economy of thousand projects

If I had a system that consistently produces projects, I could amortize money and time costs a lot.

I can use shared servers, UI templates, and even domains across many projects and save costs.

The same goes for time. If I have tools and frameworks to bootstrap a project quickly, I can save time.

The more projects I have, the cheaper it should be to support them.

I can reuse strategies and tools across all projects, even from the marketing perspective.

Selling projects

I do not plan to, but if I see that some of the projects demand enormous investment energy and stills it from the other projects, I can sell it.

For some projects, support might be dull. What’s more interesting? To ship new stuff or support the old one? It depends.

Marathon of sprints

It is a long journey, and it can take a lifetime to ship even the first ten projects. I do not want to ship fluffy stuff, and I will not perfect the stuff infinitely. I will slowly and thoroughly advance.

I do not want to burn out also. I will optimize for fun and making a buck for a living.

Final commitment

I consider it an exploration experiment, so I can’t commit. Eventually, I can find the one project to which I want to dedicate all my time and energy.

So, there is no commitment.

I can also abandon the experiment if I do not like it or it breaks my lifestyle.

Following updates

To get the following updates, you can:

Know that I am grateful to you for reading my thoughts. If I can help you or share more, please, let me know.