Ask HN: How did you acquire your first 100 users?

I started by building something simple that would appeal to a tiny group of people I understood: a pastebin service only available over telnet [1]. I posted it on /r/linux, which led to some good conversations and open sourcing what I was doing, building a small HTTP-based service (the start of our API), and having a small group of people to talk to when the product evolved.

The goal was to become a seamless publishing platform, so I built the Android app next (which brought me closer to the broad audience I wanted) and told /r/goodguyapps about it. Every time I went after a new platform -- Chrome OS, iOS, desktop via command-line, web -- I found a community that would want to hear about it and simply had a conversation. I went to listen to people's problems instead of just selling my app, and ended up learning exactly what I should build and what the product could do outside of what I'd originally imagined. Write.as didn't have user accounts for the first year and a half it existed, but somewhere in that process we passed 100 users across various platforms.

[1]: https://github.com/writeas/nerds

Answer here depends on what you're hosting and doing for the bank but generally...assuming you do not require complex integrations into BBG or proprietary tools you should be able to host off-prem. We fought hard for it and eventually got through and our clients greatly appreciate it (we can update very quickly). The key here is selling through the front office instead of the back-office. The golden rule of selling software to a bank is that clients value making a dollar more than they value saving a dollar so do your best to position your solution around that and target the front office. They'll ram it through the system if it indeed is true. PS: happy to chat further "offline/hn". Email me (in profile)

EDIT: Assuming your service is SpiderOak, from my experience/perspective this would be a very hard sell to a bank. They have (albeit inferior) solutions for this and will not trust a third party to do it easily. I wouldnt even know how to go about selling it given you would have to go through the COO and vendor department. We offer a "similar" service in that we host virtual data rooms that contain tons of proprietary / confidential data. The difference is we do it in the context of a transaction (a front-office P&L event) which makes it a much easier sell. It's also not permanent.

A word processor company named WordPerfect used a similar "feature on demand" idea quite successfully during their early years in the 1980s. They only abandoned it when it got just too unwieldy, but by then they had become the standard word processor for law firms. They eventually got sold for what was then quite a decent sum.

I don't have a SAAS app at the moment but I have had success with... Bots, influencers and ads.

Lots of people seem to think ads don't work here but, I believe it is a matter of targeting and your funnel.

I think the main issues people have when it comes to ads is they poorly execute on...

Targeting - have no idea who will actually want the product and target too broadly with a useless message or, in many cases no message at all.

When people here talk about "doing stuff that doesn't scale", what they are often doing is selling the idea before someone see's the site or product for example. Like a tweet to someone looking for a new notes app - you will normally @ them with a feature or solution right, equally with a forum post - once you know they have the problem. Do the same with your ad & targeting.

Poor sales effort - In an effort to make the page look good, people often try to have as little text as possible. In my experience, the more you say the better because you eventually touch on points the lead cares about. You simply need to make it engaging. This can be done well with a screen capture you record on your computer if you really want to have a page with minimal copy. (But test lots of copy either way)

Price/ product - most people are making stuff people don't care about and won't be interesting enough to part with money for. Might not be nice to read but in many cases, it's true.

I hope this helps.

I can't name examples, but I've worked for places where this happened, and the results were paralyzing. The only way to do it right is to add each feature as if all your customers were going to use it, but instead, people cut corners and write features in such a way that they only support the targeted customer(s). They compound the problem by adding special cases in the business logic to make sure the feature doesn't affect other customers even though it's broken for them. They add features for one customer that aren't even logically coherent for other customers. They lower their sights from "make this code work for every valid set of inputs" to "make this code work for all of our current customers, except the ones who won't notice because they don't use this feature yet."

The result is completely unmaintainable. You can't change anything because every piece of data has accidentally acquired special meaning.

"You can't remove the dog_shave_preferences column! It's how we distinguish between customers who were added before June 2013 and customers who were added after!"

The work to add a customer whose data doesn't trigger the right special case logic starts to be seen as a "new feature" rather than fixing bugs.

"Hold on, this is a fundamentally new set of requirements! We've never had a customer before who had the Bloop module enabled and had a logo bigger than 5k and wasn't AcmeCorp! We should have been aware of this new requirement before the customer went live."

The trap is how quickly people adapt to this kind of thinking, to the point where normal engineering starts to feel weird to them. I once quite seriously suggested creating a database table to record which customers a certain feature was broken for and had it shot down because people thought the byzantine special-case tests it would have replaced, which had no other purpose, constituted valuable business logic. The ideas and conditions we had invented to track the limitations of our code had started to feel like real business distinctions that they couldn't imagine living without.

Suffice it to say that eventually we slowed down to the point where declaring a feature freeze didn't feel like a drastic change to anyone, including our customers, and embarked on a substantial rewrite. It didn't end well. I've encountered another example that was a lot more sane (people knew they were doing the wrong thing all along and didn't actually start to believe in the reality of the distinctions they wrote into code) but it suffered from the same maintainability problems.