HN user
Founder & CEO at Factor House
Introducing two new open sources Clojure UI libraries by Factor House.
HSX and RFX are drop-replacements for Reagent and Re-Frame, allowing us to migrate to React 19 while maintaining a familiar developer experience with Hiccup and similar data-driven event model.
My co-founder uses the phrase minimal-viable-company for maximum-viable-product.
We bootstrapped for 5 years to well over $1M+ ARR before recently closing a seed round[1], Clojure played a large part in our ability to deliver as a small team. Also in our general happiness as programmers, it is a nice language to work in.
We will grow our Clojure core product team over the next couple of years, but mostly the funding round is about balancing our business to keep up with our product delivery.
Clojure has been very good to me (I had 15 years on the JVM prior to moving to clj/cljs in 2013-ish). YMMV.
[1] https://factorhouse.io/blog/articles/from-bootstrap-to-black...
Congratulations on building something great!
It is immensely satisfying to build something that you believe in and succeed in selling it. I founded my company in 2019 and my experiencing and motivations in bootstrapping mirror yours.
We are in year 4 (commercials) and 6 (product development) at Factor House[1].
We build enterprise tooling for streaming systems (Apache Kafka and Apache Flink mostly). Selling software to enterprise customers is different from B2C as the sales cycles can be endless and most likely your cashflow might be more lumpy, but at the end of the day it's a very powerful thing to be profitable and independent.
As @yevpats points out sometimes the bootstrapping story does miss some details, in our case we invested roughly $500k to get through the pre-commercial period, to achieve that we sold our house (my wife is also my co-founder). Not everyone can, or is mad enough, to commit resources at that early stage. To be honest we were quite mad.
Prior to starting product development with Factor House we ran a consultancy that delivered systems for enterprise customers based on Kafka, Storm, Cassandra, etc - so we had plenty of experience. We also had consultancy customers who were eager to use the pre-commercial versions of our product and provide feedback.
I also run a meetup[2] in my hometown that specialises in programming solutions with distributed systems.
Last year we took a small amount of funding from Lighter Capital (non-dilutive, fairly simple loan terms) to unlock some growth.
Bootstrapping is hard, but my interactions with VC left me with the impression that it's a low-information lottery for the benefit of those who already have capital.
It seemed clear that if we took funding we would rapidly lose control of our vision and we don't need to 100x our business to achieve our goals. I would rather focus on delivery for our users and avoid adopting manic ideas to pay off 99 failed lottery tickets.
An enterprise toolkit for Apache Kafka (and now another for Flink).
I spent years working in large enterprise orgs, a few more working with distributed systems. Along the way I picked up Clojure and by the power of greyskull managed to combine all those factors into a company. Now I work with a small team shipping tools for programmers. Good times.
Today we have users in 100+ countries, but it started off as something I needed for myself / my team when working on client projects.
Question from an Australian(ish) here.
If you Americans buy a house with an 8% mortgage today, can you remortgage in the future if/when the rate drops. Is the buy-out penalty of remortgaging somehow higher than just selling / repurchasing?
Do people get locked into higher mortgage rates for long periods of time that are uncompetitive is my question. Is there a significant downside? Is 30-year fixed normal in the states?
30-year fixed rates don't exist in Australia. You'll get a 5 year fixed rate from ~6% or so, that's about it.
Yes, sure is! https://kpow.io/
You can get started with the Community Edition for free, it includes our JQ implementation (we call it kJQ - https://docs.kpow.io/features/data-inspect/kjq-filters)
Just shout if you need any help.
This is great, JQ is brilliant.
I love JQ so much we implemented a subset of JQ in Clojure so that our users could use it to munge/filter data in our product (JVM and browser based Kafka tooling). One of the most fun coding pieces I've done, though I am a bit odd and I love writing grammars (big shoutout to Instaparse![1]).
I learned through my implementation that JQ is a LISP-2[2] which surprised me as it didn't feel obvious from the grammar.
[1] https://github.com/Engelberg/instaparse
[2] https://github.com/jqlang/jq/wiki/jq-Language-Description#:~....
I run a bootstrapped software company, not at the $100M scale.
My interest piqued I clicked, had a look at Aha! (having never heard of it before) and immediately thought - hey I could use this. You got me, ka pai, haha.
Any insight on how to navigate inflexion points that seemingly require more capital that cashflow allows? Stay true and spend less? Number 8 wire might not be the same solution today as it once was, that's my worry.
Hi @richieartoul, does warpstream support the standard Kafka Admin API?
We build an admin console / dev tooling for Kafka (https://kpow.io) that supports Kafka 1.0+ including Redpanda due to their fairly strict adherence to those API.
Warpstream seems like a cool idea, I'd like to see what happens if we plug Kpow on top of it, if that's possible.
Two Daft Punk outfits with about 70m of EL wire coupled with arduinos plugged into LED arrays stuck inside bicycle helmets. Turned out pretty good:
https://www.youtube.com/watch?v=uHrWllxRLgQ
Wrote the step-by-step and uploaded the code onto Instructables, it's still there ~15 years later:
https://www.instructables.com/How-To-Make-Two-Daft-Punk-Outf...
I made them with my girlfriend (now wife/co-founder) for my 30th, was lots of fun.
I started on the JVM in '97 at University. Damn I'm old.
The company I founded uses full stack Clojure for our product development (https://kpow.io).
We're a small team pushing through a big product roadmap at pace, love programming every day, no chance we'd have made it in Java (and I quite like Java).
Thanks Rich (and Stu, and Alex, and Fogus, and David, and..)!
You just described the last decade of my career more succinctly than I could.
Only extension being I applied the momentum boost to bootstrapping a startup and escaped the enterprise world entirely (other than sales back to that world).
Good times, lots of programming. A++ would buy again.
I have never felt like I am faking it, is that really strange?
I'm a co-founder of a company called Factor House[1]. We build a devtool called Kpow for Apache Kafka[2] and I guess you could say we rely on PLG. I can't say I had heard of the term when we started back in 2018. We are bootstrapped and have always preferred to describe ourselves as a business rather than a startup.
Kpow provides enterprise-grade Kafka tooling. It comes from our experience working with Kafka since 2012 and more broadly working in the enterprise space for much longer. I'm an old-ish engineer and when everyone else was raising we were coding, selling, and supporting.
Our growth has been slower than I expected but we are profitable and growing. We sell to everyone from startups to Fortune 500 companies. In every case the sale begins with an engineer in the client company evaluating our product after finding it themselves.
We don't spend much on sales or marketing. If you start a trial and chose not to continue with the product you never hear from us again. We cancelled our Google Adwords some time ago, that may have been a mistake but we felt we were paying for crap.
At the end of last year we soft-launched the (inevitable) free, community edition of Kpow[3]. It is scary giving away four years of hard work and the associated risk but we believe in our product and we think the best way to grow our company is to show value to engineers and make sales to organisations.
I think some advantages/disadvantages of this approach are:
Advantages:
1. The Sales That Matter Are Comparative.
For the sales that matter an engineer will evaluate three products in the market to fit the needs of their team/org. We don't need to be the first product you think of, we just need to be in the comparative evaluation. We make an expert system for experts, if our product is on-point we will win.
2. Purchasing Power Is Shifting.
Who needs top-down sales through the CTO when teams/engineers have access to AWS and some discretionary budget. We started selling Kpow on the AWS Marketplace in 2020. You can pay by the hour if you like. This model has a lot of legs in it. Counterbalanced significantly by disadvantage [1].
3. Engineers See You.
The no-bull approach pays dividends with our target audience. Our users are very supportive and we have 0% churn in 3 years of sales/renewals.
4. Focus.
We're a small engineering team, we focus on doing what we do best which is shipping working software. We also have the pleasure of being able to focus on a fixed surface area without having to broaden our pitch to appeal to investors.
Disadvantages:
1. The Sales That Matter Are Big And Slow.
We sell to plenty of companies, but it's the bigger ones who pay the bills. The enterprise sales cycle is slow and unavoidable.
2. PLG Doesn't Mean No Marketing.
We intend to switch our focus into marketing this year, there's no point having a great product if no-one knows about it. A great product doesn't make a great business and there's more to it than just coding.
3. Getting it Right is Hard.
You bet a lot on a narrow focus. We cut our first code in May 2018 and our product vision has not changed. It would be easy to get that wrong and hard to recover.
[2] https://kpow.io/
[3] https://kpow.io/community/
[4] https://aws.amazon.com/marketplace/seller-profile?id=ab356f1...
“How did you go bankrupt?” Bill asked.
“Two ways,” Mike said. “Gradually and then suddenly.”
I'm a founder and one of the point technical people for Kpow (https://kpow.io). We're a bootstrapped, self-funded, global business in a technical niche.
Kpow is a toolkit for Apache Kafka, so basically we build an expert system for experts - it's a lot of fun. We are very, very delivery focused. The idea came from my own experience through the past 10 years building things with Kafka.
I like to think I'm a fairly effective programmer. The biggest shift in my productivity came 15 years into my career when I moved from Java to Clojure for delivery. It's not for everyone, but it certainly changed my world.
If I am a good programmer it's because I started to copy my older brother who was interested in programming back in the 80's when we had a Spectrum 48k and I just didn't stop.
Since the age of 6 I have written or read programs almost continuously except for the period between about 10-18 where I played games and hung out with friends instead.
At times I have been a terrible programmer, particularly when encountering a new languages and exploring ideas. That doesn't bother me because I know in time I absorb details, accumulate, and polish my own ability to delivery.
Behind it all though I enjoy programming and have stuck with it. I think that's the main thing. It takes time. I don't believe there are any shortcuts.
Keep challenging yourself, don't sit on the thought that 'My Language Is The Best', that's the respite for programmers who have stopped. You're only as good as your last three years so basically ignore any boomers on the net with opinions.
The best programmers I've worked with don't have blogs, don't write books, don't speak at conferences. They're too busy creating things, often quietly, often in not particularly glamorous settings.
It may be apocryphal but supposedly Steven King says the best way to be a good author is to read and write a lot of books, I think that applies to programming.
We have modelled our company/product specifically on JetBrains. We're also bootstrapped, self-funded, etc.
We build a tool for Apache Kafka (https://kpow.io), it's not a SaaS product, it's a single docker container or JAR that runs in air-gapped environments, our users install it in their own network and it just runs. That's what we thought engineers wanted, and tbh it turns out we were right in plenty of cases.
Our licensing is an annual subscription however - but then again so is JetBrains (well at least for the Intellij product that I happily pay ~$150 a year for).
I think for us the recurring revenue is really important, we wouldn't be able to sell you a perpetual license as we have commercial costs that are ongoing and related to maintaining the quality of the product. Not only is it better for us commercially, but also we have only had one customer in the last three years request a perpetual license, and we we explained we don't offer that model they bought a subscription.
So I completely agree on the non-SaaS JetBrains model, and I love that you mentioned that company. We often get asked about Confluent in our area of expertise but quite honestly from day 1 in 2018 we've been aiming to be the JetBrains of distributed systems. We even followed their dark branding style.
Edit: Just to add one more bit of context now I think of it. Don't underestimate the power of the hive-mind.
We have spent four years building a boostrapped non-SaaS product. We spend all our time talking to customers, shipping features, squashing bugs - living the dream basically. That's a really rare path to follow this decade.
We've also had four years of often well-meaning people trying to intro us to low-information 'startup investors' or god-forbid another startup 'accelerator'. We stopped talking to all of them about two years ago, but for a while there we got told repeatedly to build a SaaS product.
And the single worst piece of advice I've ever received which nearly made me puke, when we were in year one of our product and already had a reasonable number of users / clusters:
"Just grab all their information and stick it in an S3 bucket, that information is what everyone wants! Number of clusters, users, version, etc - you can sell that!"
Some people just don't understand that you can sell a tool that does something valuable without making your customer base some side product that you sell on the open market.
It has been hard at times when we see startups raise tens of millions, but we're now in a position where we are miles out in front of the pack, have a rock-solid product, a great roadmap yet to go, and s stack of great customers who we respect. At no point would someone else's cash or terrible advice have left us in a better position - though we might have ended up with a SaaS product instead..
Write a lot of programs.
If you learn quickly the rest will fall in to place. Don't pay too much attention to the constant flux of industry dogma, focus on working solutions.
Stop reading HN.
If we used interop for everything mundane, Clojure would really just be an S-expression shaped husk over Java code. Not a very good solution.
Interop into the host system in Clojure is idiomatic. I think often there is a misunderstanding of the difference between information systems and artificial ones. Rich Hickey gives a plain english explanation in section 2.1 of his fantastic talk "A History of Clojure". [1]
I have been using interop into Java for the mundane for ten years. Our general approach is to simply use p/datafy to convert the result of interop calls immediately back into Clojure datastructures.
I don't find that approach onerous and it doesn't impact our overall system design any more than using a third party DSL. The interop ensures we take ownership of our Java dependencies rather than using an outdated thin DSL wrapper which provides no real value anyway (as I assume the Stripe example would be). In the past where I've worked on projects with those wrapper DSL I tend to throw them out, they're the wrong idea.
In my case I use stable, mature, artificial systems provided by Java to underpin my application. My application is an information system, where I use the lean power of Clojure to implement complex functionality without the drag of Java.
The result is an echo of the Destroy All Software talk "Funcational Core, Imperative Shell" [2], but rather more a "Data-Oriented Core, Type Oriented Shell". The end goal being to enable my small team to ship better and faster than our competitors
The most important artificial system in our application is Jetty, the networking framework. The next is the Kafka Client / Streams API. That's our Type Oriented Shell. The magic of the application is Clojure, everything in between. The glue is interop, p/datafy, and transit.
In some cases the magic, value-adding, bespoke software part a developer is attempting to add between the Type Oriented Shell parts is tiny, and the result feels like an S-Expression shaped husk. In my case that magic part is enormous, and the benefit of using Clojure obvious.
If you are shipping an information system, the problem domain is non-trivial, and you are delivering on the JVM, I believe you should use Clojure to attack that problem. For me it has been game-changing in terms of pace and quality of delivery. Right tool for the right task.
Clojure is also enormously more fun and liberating to work in than Java, and you shouldn't underestimate the power of joy as a morale maintainer when working on one problem for a long time. I first started working on our product in May, 2018 and I enjoy working on it today.
For context, I worked in Java for 15 years before adopting Clojure a decade ago so I understand the relative benefits of shipping production information systems in both languages. I'm also probably more comfortable just using Java interop than some Clojure developers.
We have plans to open-source the useful parts of our type-oriented shell and the glue that binds them in the next few months, along with our solution for managing dynamic system state, but then again I've been faintly promising that for three years so take it with a grain of salt.
The application I work on is enterprise-grade tooling for Apache Kafka: https://kpow.io/
[1] https://download.clojure.org/papers/clojure-hopl-iv-final.pd...
[2] https://www.destroyallsoftware.com/screencasts/catalog/funct...
This is my experience also (10+ years with Clojure).
Macros extend the language. I don't need to do that often. I think I've written a dozen macros in ten years and deleted all but one of them.
My current codebase has two macros, one I wrote and that only supports some repetitive behaviour in a test namespace.
Clojure's super-power is solving problems on the JVM and in the browser with one language consisting of well thought out datastructures and a suberb core library of functions that operate on those datastructures.
That, and great host interop. And Instaparse, which is a delight!
Kafka Streams is a core part of the open-source Apache Kafka project.
You may be mistaking it for kSQL, or ksqlDB as they call it now, which is a Confluent project built on top of Kafka Streams.
RE: Clojure startup times, the full Kpow web app starts in ~7s.
Do you have a reference for Clojure's 'insane amounts of memory' use?
Our product (https://kpow.io) is written in vanilla Clojure/Clojurescript, it will quite happily run with a 64MB heap for smaller workloads.
64Mb for a non-trivial full-stack enterprise-grade application with authentication enabled providing a rich UI and multiple asynchronous and/or scheduled background processes that monitor and manage Kafka resources. Sure we don't recommend running multi-cluster production workloads on a 64MB heap, but requiring further memory for real workloads has nothing to do with Clojure and we're a long way from 'insane' memory use, or doing simple things.
Clojure is as much a 'Guest Language' on the JVM as Scala or Kotlin.
We build a product in Clojure that runs on the JVM and in the browser (https://kpow.io).
Clojure/Clojurescript gives us a language/toolset that works in both the front and back ends. In some cases we have we have code in a single source file (.cljc) that works in both the browser and on the JVM with no modification.
The feature that cross-environment functionality implements in a single source file is complex in some cases (e.g. a grammar / parser / interpreter for a subset of JQ).
Both the front and back end use the same core functions and same datastructures to implement the product. Data is moved between front/back via Transit (and encoding format for Clojure datastructures).
In my experience the reduction in complexity through the stack is staggering. Once you've learned Clojure that is..
Stripe Atlas cost me US$500.
For that I got a Delaware C-Corp, an SVB bank account, and $5k of AWS credits that expired after 12 months. Our AWS bill in that first 12 months was roughly $5k.
Money well spent.
I have deployed and run Cassandra myself, basically as you describe.
The first 'dev' Cassandra install was three nodes. I downloaded the .tar.gz, installed it, started each process in turn on each node with the required configuration.
That was 2012 and there is a chance that cluster is still running. It was low-volume in terms of data. TTL configured so it would never run out of disk. Never had any issues in particular. I used it for ~5 years before concluding work with that client.
The problem in that case was Cassandra proliferated in that small company, they didn't build any particular expertise beyond me, and in the end I was being pulled into discussions from different teams, different products, split across about 13 clusters. Wasn't much fun - but that wasn't the DB's fault.
Hell of a story Dan! Congratulations on the new arrival and best wishes.