Why gitdot?

Ideas are hard.

An idea is a thought, a suggestion as to a course of action. And while worthless on their own, ideas are valuable for there are such things as “good ideas” and “bad ideas.”

Good ideas are novel, timely, and often a tad contrarian. They seem obvious in hindsight, but are hard to discover in the now. Many people like good ideas because good ideas often turn out to become big companies.

Bad ideas are unoriginal, undifferentiated, and just a bit boring. They typically lack a “why now”, a compelling narrative, and are often limited in scale. Smart people hate bad ideas: many a venture capitalist will happily tear them to shreds.

Startups tend to be defined by their ideas. There’s this notion that all you need to do is “pick right,” and that if you find the lucky few where you happen to be in the right place at the right time, success will await you. And while it is beyond our means to know if that is true or not, we’ve decided to stop looking for “the one.”

We had spent weeks brainstorming and researching more typical startup ideas, AI on-call engineers, voice agents for moving companies, construction compliance software, and gotten to the point where we had a few viable candidates in front of us.

Yet there was a feeling of dissonance when we imagined ourselves working on them. The primary complaint was that many of our ideas seemed speculative. We were building products with the assumption that they would become necessary if AI advanced in a particular way or form.

That’s something we felt quite strongly against. For one, we had been burnt by it in the past, and for two, now held the belief that the only part of the idea that really matters is whether customers want it.

Other ideas were more grounded in reality, and on paper, would convince us that it would see a profit. But it became clear that simply because an idea is viable does not mean that we have the appetite to work on it. Though you may call me schlep-blind, the idea of working on AI agents for tariff compliance does not thrill me in the slightest.

So we asked ourselves: what is it that we want to do?
Our answer was simple: we want to work on the things we like.

And what we like is building. Mikkel and I have both spent a decade in corporate tech, and though our passion for code has admittedly undulated at times, it still rekindles each time we build something new. There’s something special about it: building, designing, and engineering products.

We’re perfectionists. We care about craft and disdain the philosophy of “doing as little as possible as quickly as possible.” We take pride in what we do: from the lines of code we write to the details we design. But we also recognize that what we care about is not necessarily what our customers care about. In many industries, sales and distribution is more important than product, a fact we’re well aware of.

So we chose to serve a market that we believe does: developers. Developers are harsh, blunt, critical people unswayed by marketing or sales-speak. They are both the user and the buyer, and their purchase decision is simply their opinion of the product.
We think that’s perfect for us.

Once we made that decision, our identity became clear.
We’re a dev tools company — we build tools for developers to use.

The choice of what product to build was a logical one. We came up with a few ideas and asked ourselves: which one do we think customers need the most?

Our answer was GitHub.

What’s striking about GitHub is the relative lack of competition. Although alternatives like GitLab exist for enterprise, if you want to host an open-source project, GItHub is by and far your only option. That also means you have a strong incentive to use things like GitHub issues and GitHub actions, even though you may not like the tools themselves. We saw that as odd for the dev tools space, a market typically characterized by competition and choice.

And perhaps due to their dominance, GitHub has many features, many buttons, and is designed to be usable by anyone: whether that be a student developer or an experienced senior IC. We started to question that: whether an open-source platform should triangulate towards the norm and who it should really serve instead.

Our belief is that gitdot should be built for the maintainer.
It should be opinionated, purpose-built, and unafraid to eschew others to better serve the maintainer. We’ll continue to share our thinking as it evolves, as well as the product decisions that transpire from it, but we feel quite certain in this belief as of now.

To end on.

As of today, gitdot is just an idea.
It is on us to turn it into a product.

I look forward to sharing more soon.
Thank you for reading and happy new years
—baepaul.