<aside> 💡

Note: this is a collection of a bunch of branding questions different folks have asked us (and our opinions / answers to the questions). If you have additional questions feel free to leave comments OR shoot me a text and i’ll do my best provide more color!

</aside>

ABOUT THE COMPANY

1. How would you describe the market you are in?

We‘re in the developer tool space. We’re building a modern engineering-focused peer to linear, notion, figma, etc. (today this space is occupied by GitHub and GitLab).

1. What is your business model?

To start we’ll be launching a pay-per-seat model + additional pricing around CI. With time we’ll move upstream to larger enterprise offerings like self hosted versions of Pierre.

1. Could you share the story of your company?

We started working on Pierre ~18 months ago.

At the time we noticed that there was a new stack of collaborative tools people were using to build software products (notion, linear, figma, etc), but that GitHub (the engineering tool) didn’t fit in. Not only that, the core product offering of GitHub (pull-requests, code hosting, CI, etc.) hadn’t materially changed in the last 10-15 years. It felt outdated.

So we brought together a super team of engineers / designers / builders to work on the problem, and started rethinking code collaboration primitives from first principles.

1. What customer pain point do you want to resolve?

People have been using the same software to ship code and collaborate together for about 15 years (GitHub). AND this software is built on primitives like code diffs, CI, etc. that haven't materially changed since the 70s (and were largely designed in an era where code was printed out on paper).

Moreover, the prevailing collaborative surface (pull requests) have a number of intrinsic issues:

• they only support reviewing code before it is merged. As a result, all changes are blocking and software development is much slower then it needs to be.
• they are extremely manual and are only created when you go out of your way to document the change and attach stakeholders (this means people often miss changes they actually care about, AND many changes like commits directly to main/master aren't reviewable at all)
• They don't take into account that there are different types of engineers that care about different things, and different types of changes with varying degrees of complexity / impact