Forem: Dragos Bulugean

This bad boy got a new battery

Dragos Bulugean — Thu, 04 Mar 2021 12:37:13 +0000

This bad boy (MacBook Pro 15 late 2013) just got a new battery.

I’m hoping to keep it alive until Apple comes up with a decent pro laptop again.

I had it serviced yesterday, and I was nostalgic.

Learned Node.js (v0.11) on this device in 2013.

Got promoted to software architect working on it.

Built an AI product in 2015 on it.

Pitched a COO of an F500 company with it.

Got my 1st gig (and the next 40) as a consultant and executed on it.

Built Archbee as a diagram tool on it.

Pivoted Archbee into a docs tool for technical teams on it.

Sold $60K worth of Archbee licenses on a deal on it, first month into the pandemic.

Got it to $1M+ valuation from the first angels on it — the same year.

Now we’re close to 100 customers paying monthly subscriptions.

It sounds cheesy, but I love it. I’m not going to sell it or let it die dusty somewhere on a shelf.

The build quality, the keyboard, the retina display, the rock-solid OS, the speed of it. It’s so good.

And people saying it's not worth $500 bucks more than other laptops. It's worth $10,000 more... if you value your time.

I hope Apple can go back to this type of magic device.

What's your most loved device? Let us know down below why.

macbookpro #apple #quality

6 (crazy?) ways to become more efficient as a developer

Dragos Bulugean — Thu, 14 Jan 2021 21:51:31 +0000

Why should you read this article? I've built a SaaS all by myself and needed time for tasks other than programming, so I needed to become efficient.

I know a thing or two about developer productivity.

Read!

👇

1. Use 1 hour-long pomodoros

Pomodoro works! But for developers, the typical 25 min is not enough.

It can take up to 10 min just to warm-up and get into beast-mode.

So do whatever it takes to not get interrupted for 1hr, then get off the chair, do 10 pushups or squats.

Rinse and repeat.

2. Do a little research before writing any code

Yes, having a high-level view of what your task entails will help you.

Because... there are fewer chances of hitting roadblocks and starting over.

Because... once you have a clear view of what you need to do, you can get the hard things first so everything falls into place at the end.

3. Use a language with a tough compiler

Not shaming the JS, Ruby, or Python folks. Those are great languages and they can get your product started very quickly.

But as you reach even as little as 10K lines of code, it will become very hard to keep it all in your head. So why not trust our oldest friend... the compiler?

Use TypeScript with very strict settings. Python with type hints. Ruby with Sorbet.

If you are fancy and know what you're doing, go for ReasonML or PureScript.

Avoid fake strongly typed languages like... you know what we're talking about.

4. Documentation

Documentation has very low ROI at the beginning of a product/company. Because there are high chances of pivoting. Because there are very few people to share it with.

As soon as you hit a team of 10, docs are important.

But keeping your stuff in GitHub wiki is detrimental to your productivity. Contrary to popular developer belief, markdown in git repositories is not a productive way to share and contribute to team documentation.

Here you can use Notion, Google Docs, Confluence. Or why not, just use Archbee my product. It has some cool features for developer documentation.

5. Unit tests

This is a huge time drain, and we hate to write unit tests. Unless you're Uncle Bob.

Ditch classes wherever you can. Classes are for suckers. Sorry, but it's true.

Write pure functions with a single responsibility. Coupled with a tough programming language, you should be ok with just a few unit tests.

But write tons of integration tests. Test at the UI level with Cypress. That will make sure everything from the UI to the Database is hit, so you can have more confidence you're shipping ok code.

In my opinion, unit tests are one of those things you should take the Pareto approach with.

6. Avoid meetings & team chat

To have as many of those 1h pomodoros as possible, you need to shift your approach to one that's more asynchronous. Write more docs, cancel more meetings, stay off the team chat. Certainly don't spend time organizing JIRA tickets.

What would you add?

The Only Way To Grow

Dragos Bulugean — Fri, 08 Jan 2021 10:06:13 +0000

I thought I'd let people know about the constant rejection that I've been getting since starting Archbee. It's tough, y'all.

YCombinator rejected me 3 times:

W2019 didn't even hear back from them.
S2020 they invited me to an interview, did the interview, and then rejected me after a couple of days.
W2021 (was still in 2020) invited me to an interview again, but still rejected me. Even after being #1 on ProductHunt, having lots of great reviews, and showing revenue growth. 2 Tier-2 accelerators also rejected me.

In 2020 I talked to 18 angel investors. 12 rejected me.

Also in 2020, I talked to 8 VC firms. 5 didn't provide any feedback. The other 3 rejected me.

I looked in my calendar for sales calls, about 100 since mid-2019. 70 rejected me, the others bought the software. Some of those churned, so that also counts as a rejection.

I asked 3 of my developer friends to become co-founders. All rejected me.

I asked 2 people I met on Zoom to become co-founders. They rejected me.

I tried 3 cold outreach campaigns with hundreds of people in them. Some responded, but 0 customers, all rejected me.

I asked 2 friends to invest in Archbee. Rejected.

I asked some people with a good audience on Twitter to tweet about our ProductHunt launch. Nobody did.

I tried to sell an Archbee subscription to a CTO I used to work with. He said "what if you get hit by a bus?" knowing that I'm building this by myself. So cruel.

I asked for help many times. VERY few people did.

Seeing it laid out here feels even worse.

But I completely understand why it happened when I analyze my own rejections of other people.

I also rejected 1 accelerator, 3 angels. I fired 4 customers (yes, I did). Some co-founder requests. Rejected all 5 VC firms who didn't bother to tell me anything, by not following-up with them. I also rejected many people pitching me their services. And 300+ candidates on my job ads on LinkedIn. I fired my 1st employee.

It's how we work as a species. By default, we don't believe. We are "no men". We don't submit to requests. We only help if it's 0 or 0.1 effort. If it's 0.5 or more effort, then we have to gain something as well.

But... it's most likely the way it should be. To maximize the chances of survival.

Man up, face rejection. It's the only way to grow.

EDIT: Not looking for "hang in there" or hug emojis with this post. Just telling developers how fucking hard it is to bend the universe to your will.

EDIT: I wrote this for other developers that are trying to change the world in any meaningful way. You are going to go through the same thing or worse.

How I Learned React and Built Archbee

Dragos Bulugean — Tue, 21 Jul 2020 17:44:06 +0000

As a developer, you know it's not good to stay in your comfort zone for too long. Technology changes too fast.

So after a couple of years of doing backend Java, I tried to learn frontend.

That was 2013, when Angular 1 came around.

I learned Angular and I enjoyed it, but went back to doing backend with Node.js for a couple years.

When React came along, I didn't think it would get big.

Like a lot of other developers.

Boy was I wrong...

But in 2015 I recognized I was wrong when I read all the material about React's philosophy.

So I learned React on the side, as I was also doing consultancy on backend Java.

That turned out to be a really good choice because it allowed me to not rely on other developers to build a full product.

When my first idea came along, I built it myself in 2 months in my spare time.

That was Archbee v1, a diagramming app for software architects.

It failed to get traction on its own, so I tried something else.

The foundation for the second idea was that documentation for software teams was an unsolved problem.

Documentation is much more than text.

It's diagrams, API docs, notes, know-how, bottlenecks, legacy information, changelogs and so on.

But no solution existed that would address all those usecases so I decided to build Archbee v2 as a documentation tool for developers and dev teams.

Give it a shot at https://archbee.io and let us know what you think of it.

P.S. We have some dev teams that say they prefer it to Notion!

The golden age of SaaS

Dragos Bulugean — Fri, 15 Nov 2019 10:54:24 +0000

Most people overestimate what they can do in one year and underestimate what they can do in ten years.

Most likely, this Bill Gates quote refers to building businesses. It can take a lot of effort and persistence. Building a SaaS business is a 10-15 year journey.

I would like to extend this to developers.

Most developers overestimate what they can build in 3 months and underestimate what they can do in one year.

When I started writing code for Archbee in December last year, I thought if I go full-time and perform my best I can build a decent product (compared to competitors) in 3 months.

After 3 months, I had a product made of tangled code, barely working, low feature, buggy, not even friends wanted to use.

Almost 6 months in, first paying customers, I almost had to beg not to leave due to still buggy and no features. Good people, but still, the product didn't deserve it.

9 months in, some early signs of traction, the product in ok shape, but 55k lines of still tangled & messy code. But looking way better from the outside.

I took the next month rewriting almost everything and not worrying about new features as the product was at 95% parity to my competitors. And some extra ones they didn't have 💪.

11 months in, I saw some companies choosing my product over big competitors. Mature competitors. VC-funded competitors. Bootstrapped competitors.

This is a reminder to developers that they can go build businesses for themselves. You don't need connections, venture capital or anything else. The only requirement is a strong mind. It's mental more than anything else.

When you do decide you want to get investment, your company will be a beast in their eyes. Because you deserve it.

You went through all the adversity necessary to earn the respect of investors and make them believe in you without saying one word. Your MRR and MoM growth tells the whole story.

If you decide to keep bootstrapping, you're still in very good shape having been in the trenches for so long. The longer you stay bootstrapping the more valuable you become because you don't need anybody and anything.

Do it.. there is nothing you'll regret more if you don't. Imagine yourself. 45-50 years old, knowing you've been through the golden age of SaaS and you did fucking nothing.

❤️

Why don't developers build more startups?

Dragos Bulugean — Wed, 11 Sep 2019 13:30:09 +0000

A startup's first main hurdle is to build the product or a small version of it. In 2019 it can cost you anything from 50k to 200k and 3 to 12 months to get going.

With this in mind, you would think developer founded startups would pop up all over the place. Because as top 3 percenters, they could self-fund the product or even build it themselves.

But as you probably noticed, this is not a trend. More and more developers remain employed and less and less become founders. There is nothing wrong with this, but I've always wondered why.

So I've asked all my dev friends and a bunch of devs on the internet. There seem to be 3 main reasons for this.

They say they don't have good product ideas or the good ones they do have are already taken;
Even though they have great salary, they can't put aside much money;
They are not convinced they can do it, because a big part of building a startup does not involve technical skills.

While all the above are reasonable answers, I want to express my thoughts on number 1, which was by a landslide the most common answer.

There seems to be this ingrained belief among developers that you have to build something innovative. That you have to come up with something absolutely new, and it's shameful if you don't.

In my opinion, this is completely wrong and harmful. Especially for developers. Developers have the best chances to build successful startups, and especially B2B SaaS startups.

Developer founded startups can compete very well, even with VC-funded startups, because they are (or can be) time-efficient & capital-efficient. This is because developers, with little effort, can become T shaped. Or if they can't, they can hire contractors for those positions, until they learn the ropes, or until they can afford to hire full-time.

This is one of the reasons YCombinator startups are doing well. They pick technical founders most of the time, and they make it in the long-run because of their ingrained efficiency mindset.

Circling back to innovative/unique ideas. You don't need them. If you do get one, it's going to be a lot harder to make it happen, because you have the educate the market, if it turns out your product is needed. Which is definitely out of your skill zone.

As a developer, your best bet is to go build a product in a market where real money is being spent already. There will be competition and you will have to fight. There is no shame in that. But there is shame in seeing competition and then backing down.

But know you have the advantage. Most VC-backed founders have to swing for the fences. They have 1 year and a half of runway to prove they are worthy of the next round of 1 year and a half. They have to keep paying the people they hired to be able to swing.

You are free of all that. You can build a business that makes 100K a year, 1M a year, or even 100M a year. You decide when to stop and when to step on it. Stay lean, keep jogging.

Lao Tzu said "The flame that burns twice as bright burns half as long". Take advantage of that.

Why did I write all of this?

3 recent customers of Archbee came from one of my weaker competitors, who is probably shutting down from what I understand. They swung for the fences and lost. They even had 3-4 years in headstart. I didn't even have to compete, they killed themselves.

Willing to bet that a lot more will be weeded out through the years, in the same manner. And my strong competitors? I am happy to compete. I know where I have the advantage, and where I don't. I will happily compete even where I don't.

You should be happy to compete in a multi-billion dollar market.

So stay away from 'unique' or 'innovative' ideas. AI, cryptocurrency or self-driving startups or whatever is cool at the time.

Go to an established market, built a great product, be efficient, keep your head down, keep building.

Go 🚀my fellow developer. DO IT!

Just because you can build something doesn't mean you should

Dragos Bulugean — Fri, 06 Sep 2019 08:43:39 +0000

I could probably write a small book on the mistakes I've made in my first year as an entrepreneur.

Most of them come from the fact that I am an engineer at core, and my obsession with exhaustiveness. It's excellent to have as an engineer, really bad to have as a founder.

I wanted to silo the product from other products. Because I thought most of their features could be bundled into one and made better this way.

I've learned the hard way that: just because you can build something doesn't mean you should.

It will be harder to maneuver & pivot in the long run. Harder to market and sell a bunch of things put together. Harder to pitch to pre-seed level investors. Harder to network. Just harder overall, and for no good reason.

I am starting to correct it though. Yesterday I released 21 integrations for Archbee.

GraphQL, Swagger, Github Gist, Numeracy, Codepen, Mode Analytics, Slack, Airtable, Trello, LucidChart, Typeform, Mindmaster, Prezi, Miro, Invision, Figma, Framer, Abstract, Marvel, Google Analytics, Intercom.

Check them out right here: Archbee Integrations

No product is an island, the power of the ecosystem is huge. Why not benefit from it and at the same time make it better? Win-win.

I am curious and willing to learn from other people's mistakes as well. What mistakes did you make and what steps did you take to correct it?

Let me know down below!

10 open source tech you should take a look at, before 2020

Dragos Bulugean — Tue, 30 Jul 2019 06:51:38 +0000

At the beginning of the year, when I started building Archbee, I evaluated some cool tech out there. Here’s the list of the tech I think will change the world in ways we can’t even predict.

1. Swift

Objective C was perceived as clunky/verbose by many, and hard to teach to younger developers. So Apple decided to brew their second programming language, Swift.
They recruited Chris Lattner, notorious from his work on LLVM and conceived one of the most impressive languages ever.
What many don’t know is that Swift is open source, and has a big and growing community behind it. They made Swift work on Linux, created Swift Package Manager and are making Swift a workable server-side language, all happening in a very short amount of time.
Take a look at a SwiftUI intro from Twilio:

So why should you invest your time in learning a bit of Swift?

Borrows heavily from functional languages with features like: non-nullable types, immutable data structures, first-class functions, higher-order functions, sum types with exhaustive switch patterns, partial and pure functions, tail-call optimisations for recursion, extensions and many more; Swift is no Haskell, but goes a long way from classic OOP languages like Java and C#;
Swift is compiled to LLVM bytecode, so no CPU cycles will ever be wasted;
Has Automatic Reference Counting for memory management. Although it can’t compete with something like compile-time memory management in Rust, in my opinion, ARC is the second-best;
SwiftUI is a great UI library by Apple — heavily influenced by React, it proves once again that the ideas behind React are great: top-down data flow, immutability and language level declarative views. SwiftUI is not open-source but it’s so cool that it deserved to be on the list;
Growing server-side ecosystem — Vapor and Kitura both great for writing backend systems; a bit immature, but very workable with;
XCode is a very mature, fast and editor that is a pleasure to work with.
Swift playground makes it easy to learn and experiment because of its immediate feedback, no compile required.
Swift’s future is bright because of the active and excited community; One of the highest paying jobs;

2. Kotlin

A bit of the same story as Swift, Kotlin came to life as a modern less verbose Java alternative on the JVM.
Surprisingly, this great language was created and is being developed by JetBrains, a company that makes code editors.
Kotlin became popular through Android, when Google made it an official language for its OS, but is becoming a monster alternative for Java in the server-side world too, mainly because Spring Framework made it a priority to have it as first-class citizen.
Quick intro from Kotlin’s project lead:

So why should you invest your time in learning a bit of Kotlin?

Kotlin is multi-platform, meaning you can compile it to JVM, LLVM (and WASM by association) and JavaScript, covering most use cases;
Modern type system with non-nullable types, generics, comprehensions, and great influences by functional programming languages. Arrow is an excellent addition to its standard library, take a look here: https://arrow-kt.io/;
Server-side Kotlin can benefit from one of the most mature server-side ecosystem built over more than two decades since Java/JVM was introduced; Coroutines make it a great programming language to build scalable asynchronous web APIs, but unfortunately, most libraries will block as they were designed for the old thread-per-request paradigm.
One of the best IDEs out there — IntelliJ IDEA;
React bindings for when you compile to JavaScript to build web apps. Compile to executable files like Rust or Go.

3. Kubernetes

When Docker came around, many developers didn’t see the value. Dependency isolation seemingly was not enough for most to make the switch from bare VMs running in the cloud.
After Google to open-sourced their internal project Borg, everybody started to see why containers and container orchestration are the way of the future for running systems in the cloud and on-premise.
Quick video explanation of Kubernetes:

So why should you invest your time in learning a bit of k8s?

Declarative infrastructure means you’ll be done with error-prone manual configuring of your system. Yes, YAML is not the best, but solutions like Pulumi make it a lot more reasonable;
Distributed systems are more resilient, and Kubernetes makes it a lot easier to build one;
Almost Hands-free scaling by just running configuration changes to add nodes or scale containers;
Automatic revival of dead/crashed containers, with zero downtime deployments;
Readiness and liveness probes for containers;
Small to no attack surface if you create your cluster in private networks, only exposing through Ingresses;
Greater security than self-managed servers: most hosted k8s clusters will have great security defaults right out the box;
Most cloud providers will provide you with a free k8s master, so no actual resources will be added to your cost;
As long as you can package your services as Docker containers, everything will work 100% the same in development and in production, making the development process faster;

4. Elixir

What a beauty of a dynamic functional language! Built on top of the rock-solid Erlang VM and benefitting from the ecosystem and stability, Elixir marks the spot as one of the crucial technologies developed in the 2010s.
They said it best on their homepage so I’m just going to quote it:
“The unavoidable truth about software running in production is that things will go wrong. Even more when we take network, file systems, and other third-party resources into account. To cope with failures, Elixir provides supervisors which describe how to restart parts of your system when things go awry, going back to a known initial state that is guaranteed to work: The combination of scalability, fault-tolerance, and event-driven programming via message passing makes Elixir an excellent choice for Reactive Programming and Architectures.”

So why should you invest your time in learning a bit of Elixir?

Functional language with immutability by default, first-class and higher-class functions, pattern matching, structs, sigils; Phoenix Framework is really great, taking some hints from Ruby On Rails in productivity but scales a lot better and easier on the computing resources;
Already true, but in the 2020s non-realtime applications won’t be acceptable anymore for user experience. This means that any language/platform with a focus on realtime data sync and WebSockets will have the edge, and Erlang VM + Elixir does it best in my opinion; Read up on the story of how WhatsApp team productivity skyrocketed with very low computing resources here: https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/;

5. Elm

Elm is a delight. A very simple programming language with guarantees like no other.
Have you heard of the expression “Zero runtime exceptions”?. That comes from Elm.
Its Haskell inspired type system allows it to do this, meaning you’ll sleep better at night.
Elm is also very specific on what problem it solves — frontend development. In my opinion, this is a great choice by Evan Czaplicki acknowledging that “catch-all use-cases” languages won’t cut it anymore.

So why should you invest your time in learning a bit of Elm?

Rock-solid type system means you’ll refactor easily because the compiler will guide you;
Zero runtime exceptions in practice;
Built-in toolkit for building user interfaces called The Elm Architecture (TEA). TEA is so great it inspired lots of clones in many other languages;
Compiler is top-notch: set the new standard for error messages in the industry, very fast, type inference works great;
Great ecosystem with “Enforced Semantic Versioning” meaning your dependencies will always know if something is broken or not — at build-time;
Best asset size in the industry — smaller than React and even Preact.
As you can see Elm has constantly set a bunch of new standards in our industry. Def one of the top innovations of the 2010s.

6. Flutter

Building native UIs is a very hard task. Add that you need to do it for 4–5 operating systems, and you’re in deep trouble. This is why Google started building Flutter, initially focusing on Android and iOS, and eventually adding the Web Platform and even macOS and Windows apps soon.
Take a look at this video:

So why should you invest your time in learning a bit of Flutter?

Helps you build performant mobile apps;
Great backing from Google, which apparently is trying to build another OS called Fuchsia based on Flutter UIs;
Dart 1 is kind of boring and old-school, but Dart 2 is more functional programming oriented, and also very specific on solving UI problems best; Flutter’s hot reload helps you quickly and easily experiment, build UIs, add features, and fix bugs faster. Experience sub-second reload times, without losing state, on emulators, simulators, and hardware for iOS and Android.
Delight your users with Flutter’s built-in beautiful Material Design and Cupertino (iOS-flavor) widgets, rich motion APIs, smooth natural scrolling, and platform awareness.
Dart + Flutter has great IDE support in Intellij IDEA and Visual Studio Code;

7. Redis

From their homepage:
“Redis is an open-source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.”

So why should you invest your time in learning a bit of Redis?

Redis is insanely fast;
Redis is a very versatile toolkit;
You can use it as a cache store, database and message broker;
You can use it as an in-memory data structure store, which is the most important aspect of Redis in my opinion. In the era of microservices, if you need some shared state that you need to modify concurrently, you basically have no choice but to use Redis;
Most cloud providers will provide a managed Redis service for you;
Bindings to most programming languages;
Very small API surface, and very intuitive;
Very scalable through high availability and automatic partitioning.

8. TensorFlow

TensorFlow is Google’s machine learning toolkit. From their homepage:
“TensorFlow is an end-to-end open-source platform for machine learning. It has a comprehensive, flexible ecosystem of tools, libraries and community resources that lets researchers push the state-of-the-art in ML and developers easily build and deploy ML powered applications.”
TensorFlow’s core strength is performance. It was built for taking models from research to production at massive scale and it delivers. Persevere and you’d be able to join the ranks of ML practitioners who use it for incredible things, like finding new planets and pioneering medicine.
The TensorFlow community put in a lot of elbow grease to make the initial magic happen, and then more effort again to polish the best gems while scraping out less fortunate designs. The plan was never to force you to use a rough draft forever, but perhaps you habituated so well to the discomfort that you didn’t realize it was temporary.

So why should you invest your time in learning a bit of TensorFlow?

High-performance machine learning library
Bindings to high-level languages like Python, JavaScript and Swift;
Can run on both CPU and GPU;
Scalable horizontally;
Many available trained models;
Huge community, and backed by Google and a lot of big companies;
Keras — the higher-level abstraction is now built into Tensorflow;
Tensorflow 2.0 coming soon — “TensorFlow 2.0 focuses on simplicity and ease of use, with updates like eager execution, intuitive higher-level APIs, and flexible model building on any platform”.

9. Istio

Many organizations migrated their existing monolithic workloads/systems to Kubernetes.
But that is not where Kubernetes provides the most value, it’s in microservices architectures.
But this new way of writing systems brings a new set of problems with it, like: observability, connecting, controlling and securing the microservices. This is where Google saw the opportunity to build Istio, a service mesh.
If you are more on the DevOps side, you def need to take a look at Kubernetes and Istio.

So why should you invest your time in learning a bit of Istio?

Istio is very high performance, written on top of Envoy (C++);
Helps you solve most of the problems that arise with microservice-based architectures;
Side-car design pattern: most of the stuff every microservice needs to perform (logging, security, figuring out DNS, rate-limiting) will be moved out of the microservice into a “side-car”. This means less code (and error-prone) in each of your microservices;
If you run on Google Cloud, you’ll be able to benefit greatly by their integration and ease of deployment.

10. The ELK

“So, what is the ELK Stack? “ELK” is the acronym for three open source projects: Elasticsearch, Logstash, and Kibana. Elasticsearch is a search and analytics engine. Logstash is a server‑side data processing pipeline that ingests data from multiple sources simultaneously, transforms it, and then sends it to a “stash” like Elasticsearch. Kibana lets users visualize data with charts and graphs in Elasticsearch.”

So why should you invest your time in learning a bit of ELK?

Best in Class User Interface for Data Analysis;
Data Visualization for the Amazing price of… Free;
Extendable Source and Aggregation;
Hosted by many cloud providers;
Very versatile — works from ingesting logs, to text search, to filtering through huge datasets.

Article originally published at https://archbee.io/blog/10-open-source-tech-you-should-take-a-look-at-before-2020

A story of success and guilt

Dragos Bulugean — Tue, 02 Jul 2019 06:01:52 +0000

Developers, I'd like to share a success story of using open-source technology to build a product.

I started https://archbee.io as a pet project, wanting to learn this obscure thing named SVG. I was mostly a Java backend developer at the time and thought I should step out of my comfort zone and learn to build something cool with it.

Built this thing which was a software architecture diagramming solution. Well... solution was too much to say, it was almost laughable when I launched. But somehow, a small number of people loved it and kept using it. Very small amount of traffic came everyday from me answering some Quora questions, but just enough traffic to keep me going mentally.

The pet project was a really quick vanilla Javascript and Jointjs (a diagramming framework) on the frontend and bare Node.js and MongoDB. All running on a very cheap $10/m Scaleway machine somewhere in Germany :)

After I determined I could make a product people would pay for (knowledge base for dev teams), I started changing my tech options so I could peacefully work on this 10 years and even have other people contributing to this code base.

So I did it. Went with strict mode TypeScript for everything and rewrote the front-end in React and Next.js. Then I was kinda meh about MongoDB and spent another day changing it to Sequelize + PostgreSQL. I couldn’t find a good enough UI for PostgreSQL and I said let’s use MySQL & Workbench in dev and when I deploy I’ll just change the Sequelize driver back to PostgreSQL. As you can probably tell, this didn’t work so I got stuck with MySQL - that’s how I picked it :), but I’m happy it turned out this way, I like it very much. Then I realized I needed to make this whole thing realtime to offer superior user experience and I needed a Redis for PubSub and socket.io.

I realize I’m riding on open-source and sometimes I feel guilty for contributing almost nothing back. I’ve always said I love open-source but my words didn’t match my actions, and they still don’t.

Does anybody else feel this way?

Check out the latest incarnation of the product I am talking about on ProductHunt! I'd love to hear your thoughts, questions and feedback!

https://www.producthunt.com/posts/archbee-2
https://archbee.io