What two unusually simple software businesses taught me about technical novelty, community feedback, commoditized markets and finding something worth building
For much of my career, I have naturally associated valuable technology with difficult technology. I am an engineer and developer. I enjoy algorithms, AI, automation and systems that solve technically difficult problems. When I think about building software, my instinct is therefore to ask what new capability can be created, what can be automated that could not previously be automated, or where a technically better solution might create an advantage.
Recently, two remarkably ordinary software companies disturbed that assumption: Jotform and Tally.
Both build forms.
And the more I studied how they grew, the more I started questioning whether I had been placing too much importance on technical novelty and too little on something much less glamorous: finding ordinary problems, staying unusually close to the people experiencing them and improving the solution for a very long time.
1. Jotform Looked Almost Too Simple
I originally came across two posts by Jotform founder Aytekin Tank on Reddit: one explaining how he landed his first 1,000 users, and another discussing the financial discipline behind growing Jotform to more than 30 million users.
The scale immediately caught my attention. Jotform was bootstrapped, began around two decades ago, and eventually became a business generating more than $100 million annually according to the founder's accounts discussed in this research.
The product category made the story considerably stranger. Forms are not frontier AI. They are not robotics, advanced optimisation or some new computational capability. A form takes information from a person and turns it into structured data.
Of course, Jotform today is much larger than a basic form builder. It contains payments, integrations, workflows, signatures, enterprise features and many other capabilities accumulated over years. But the core interaction remains extraordinarily familiar.
What interested me even more was how unremarkable many of Tank's early-growth activities appeared. He talked to users, participated in communities, made the product easy to try, personally helped people build forms, watched how people interacted with what he had created, produced useful content and kept showing the product to people who might need it.
There was no obvious secret hiding behind the first thousand users. There was a great deal of direct work.
2. But Jotform Had An Advantage I Cannot Reproduce
There was an obvious problem with taking too much inspiration from the story: Jotform started around 2005–2006.
Web applications themselves were much less mature. A browser-based drag-and-drop form builder was substantially more novel then than it would be today. The market Jotform entered was not the form-builder market of 2026.
That matters. It would be easy to look at Jotform twenty years later, admire the bootstrapping story and conclude that I simply need to find another basic piece of software. That would ignore the conditions under which the company actually started.
This initially weakened the lesson considerably for me.
Then I found Tally.
3. Tally Removed The Easy Explanation
Tally began in 2020. By then, nobody could reasonably argue that online forms were an untouched category. Google Forms existed. Typeform existed. Jotform had already been operating for well over a decade. There were many other alternatives.
Someone on r/SaaS eventually asked almost exactly the question I was asking: how does something like Tally succeed when there are already so many form builders?
That question led me much deeper into Tally's story. The founders did not discover a new technical primitive. Their argument was closer to the opposite: forms had become unnecessarily complicated, expensive and constrained. They tried to build something they themselves wanted—simple, pleasant and unusually generous.
Their freemium model was particularly aggressive. Tally has described roughly 99% of its functionality as available for free, while charging for the capabilities that more serious users and organisations eventually need.
The early numbers were not spectacular in the venture-capital sense. Their account of the first year describes reaching approximately 11,000 users and $5,000 in monthly recurring revenue. (Tally: Year 1)
But they kept going. Tally later documented reaching $150,000 MRR while remaining bootstrapped. (Tally founders on r/SaaS) By 2026, the company reported reaching $5 million ARR. At that point the team had grown to 11 people—larger than the tiny founding team I initially remembered, but still remarkably small relative to the revenue being generated. (Tally: The road from $4M to $5M ARR)
This was harder for me to explain away. Tally had entered an already commoditized category and still managed to build a substantial business.
4. What They Actually Did In The Beginning
What resonated with me most was not the eventual revenue. It was the behaviour before the revenue existed.
Tally's founders repeatedly describe spending their early period around the people they hoped would use the product. They interacted with startup founders and creators, contacted potential users directly, asked for feedback and made improvements quickly. Their product remained unusually accessible because most functionality was free.
This created a much shorter loop than the one I have sometimes followed when investigating software opportunities.
My natural engineering loop can look like:
interesting problem → technical analysis → architecture → sophisticated system → eventually find users
The loop I see in these stories looks much closer to:
people → problem → simple product → usage → feedback → improvement
That distinction matters personally because I do genuinely like building software. The lesson I am taking is therefore not that I should stop being a developer and become a marketer. Nor do I think algorithms suddenly do not matter. There are businesses where technical superiority is overwhelmingly important, and the extraordinary economic value created by leading AI companies makes that difficult to dispute.
But not every useful software business has to live at that frontier. There are still people trying to do very ordinary things.
5. Commoditization Does Not Necessarily End A Market
This may be the part of the investigation that changed my thinking the most.
Previously, I would have treated a crowded category as a significant negative signal. If twenty companies already offer essentially the same underlying capability, what exactly is left to build?
Tally suggests that this question may be too crude. The underlying capability can be commoditized while the experience surrounding it remains poor for a particular group of people.
Forms existed before Tally. The problem was not that nobody knew how to put text fields and buttons on a webpage. Tally's opportunity appears to have been closer to dissatisfaction with the combination of complexity, restrictions, pricing and user experience offered by existing products.
This is what I now find interesting about incumbent bloat. A mature software company gradually serves many kinds of customers. Features accumulate. Enterprise requirements accumulate. Pricing structures change. Old workflows have to remain supported because existing customers depend on them.
A much smaller entrant does not necessarily have to reproduce the whole system. It can choose a narrower population and ask what that group would want if the software were designed again today.
That is not automatically a business opportunity. Switching costs are real, incumbents can copy features, and being slightly simpler is rarely enough to persuade people to migrate something important. But it makes me much less willing to dismiss a category simply because many products already exist.
Competition proves at least one useful thing: people already use and sometimes pay for the underlying capability.
6. The Community Still Matters
There is another part of this that I do not want to generalise too quickly.
Tally's generous freemium approach fits startup founders, creators, students and very small teams unusually well. These groups often have little money, experiment with many products and communicate publicly about what they use.
A developer community may respond differently. There, open source can provide a similar form of unusually high initial value. Developers may adopt something because they can inspect it, modify it, self-host it or integrate it into their own systems. Commercial value can later appear around hosting, collaboration, enterprise administration, reliability or support.
I found it useful to turn this distinction into a rough working assessment of how naturally a free or community-led strategy might work for different groups:
| Community | Free/community strategy attractiveness | Why |
|---|---|---|
| Developers | 9/10 | open source → individual developer → team/company is an excellent ladder |
| Startup founders / early startups | 9/10 | highly reachable, experimental, naturally grow into teams |
| Creators | 7/10 | very reachable and tool-hungry, but willingness-to-pay varies enormously |
| Students | 5/10 alone | fantastic adoption, terrible immediate monetization unless they graduate into your commercial ICP |
| Generic consumers | 4/10 | enormous audience, weak monetization and brutal distribution |
| Traditional SMBs | 7/10 | better willingness-to-pay, but “community-led freemium” usually works less naturally |
| Specific professional communities | 8–9/10 if well chosen | smaller but potentially much stronger pain/WTP |
These are not measured scores or judgments about the value of the communities themselves. They are provisional estimates of how easily free adoption might develop into paid commercial usage.
Other communities could require different entry mechanisms entirely. The important point is not that freemium wins or that open source wins.
The unanswered question is whether there is some form of value that a particular community cares about disproportionately, while also containing a believable path toward commercial usage later.
That last condition matters. A large group of enthusiastic free users can still produce a terrible business.
7. Forms Are Probably Not The Important Part
I briefly started wondering whether I should search for another form-like product. That also seems too literal.
Forms are one ubiquitous software primitive: people repeatedly need to convert human input into structured information. There are many others.
For example:
- speech becomes text;
- documents become signed agreements;
- meetings become notes and actions;
- files become shareable links;
- calendars become bookings;
- PDFs become structured information;
- raw data becomes reports.
Many of these capabilities are becoming increasingly commoditized.
Speech-to-text particularly interests me because modern models have made transcription dramatically more accessible. But simply releasing another transcription application would not reproduce what I find interesting about Tally.
The relevant question would be who repeatedly uses transcription and what happens immediately before and after it. A founder speaking an idea, a developer describing a bug, a consultant leaving a client meeting and a field engineer documenting an inspection may all use the same speech-recognition technology while requiring completely different software.
The primitive may be commoditized. The workflow may not be.
I do not yet know which, if any, of these areas deserves pursuing.
8. I Had Been Looking For Problems Differently
This connects with something I had already begun learning through a completely different investigation.
I recently spent considerable time researching proposal and RFP automation. The research was useful, but eventually exposed a weakness in how I was searching for opportunities: I could construct increasingly sophisticated theories about a market while remaining surprisingly far away from the people actually experiencing the problems. That earlier realisation is described in I Was Looking For The Right Problem In The Wrong Way.
I started moving toward a different approach—participating in communities, observing problems people voluntarily describe, trying to help where I can, and allowing their responses to correct my assumptions.
That approach is the subject of What Reddit Changed About How I Study Problems, where I examine how community feedback can correct assumptions about worthwhile problems.
Jotform and Tally now give that idea a software-development counterpart. Perhaps my problem was never that I enjoyed building too much. Perhaps I was allowing the desire to build to arrive too early.
It is the same broader distinction explored in The AI Is Not The Proposal System: the useful system is larger than the impressive technical capability inside it.
I can continue doing what I genuinely enjoy—developing systems, automating things and improving software—while changing what earns the right to consume that effort. Instead of deciding that a sophisticated technical system ought to exist and then searching for customers, I can stay close to a group of people, solve smaller problems, watch what gets used and allow repeated demand to pull the software in a particular direction.
That sounds less intellectually impressive than inventing the next major algorithm. It may also be much harder in practice. Staying close to users for years, responding continuously, resisting feature bloat and remaining patient while revenue compounds slowly requires a different kind of discipline.
Jotform took roughly two decades to become what it is today. Tally's story compresses the timeline considerably, but even there the interesting result did not appear after three months.
9. What I Want To Explore Next
I am not concluding that there is a simple formula hidden inside these companies. Two successful form builders cannot establish a universal theory of software entrepreneurship. Survivorship bias is obvious: many founders have undoubtedly talked to users, offered generous free products and still failed.
Nor do I know whether Tally's exact approach would work in another category. What these examples have changed is the set of questions I want to ask.
When I encounter a simple but crowded software category now, I am less interested in immediately asking whether the underlying technology has already been solved. I want to know:
- Who is still unhappy with the existing products?
- What has become unnecessarily complicated?
- Which users are poorly served because incumbents need to satisfy much larger markets?
- Can I realistically spend enough time around those people to understand their problems?
- Is there something unusually valuable I can give them with very little friction?
- If they eventually become serious users, is there a natural reason they would pay?
I still care about technology and I still want to build systems. But Jotform and Tally have made me considerably more interested in the possibility that the next valuable thing I build may not begin with an impressive technical idea at all.
It may begin with something embarrassingly ordinary that a small group of people keeps asking to make better.