Ask HN: How did you figure out your SaaS? - <AUTHOR> I can't stop thinking about starting a SaaS, how incredibly giving and good experience it would be. But I just can't figure anything out. I keep thinking "everyone else does that, I probably won't bring anything new to the table". I guess this is not the way I should think about it, as just coding, launching and getting feedback would be really good for me. How did you go through the pre-coding stage? <comment><USER2> One good method is when you walk into a business. _pay attention_ to how they manage their tasks.

Say, for example, you go into a carpenter's shop, and you see that he writes down what you want built on a scrap of paper. That's your "in". Ask if all orders are stored on paper. "Oh? I'm nikentic, and I build software for businesses. Where do you store these papers? How are you tracking receivables? How are you tracking the progress of each piece? Do you store your customer's email?"

Ask them these questions, in as much detail as you need, using your knowledge of what's possible with technology to make suggestions. You will be pleasantly surprised how much details they are willing to share about their businesses. Ask them if they would pay XXX/month for a system that covers all the major pain points they mentioned. If they would, find other carpenters and ask them if they would be interested. If you get enough interest you might be on to something. Also, how many devs are out actively looking to create software for carpenters?*

*Where carpenters = small - medium companies that are not in the technology sector.

</comment><comment><USER3> A bit unconventional..but I picked the kind of problems I like solving/working on and then looked at how those interests could align with a business perspective. Keep in mind my target was doing something with NLP which in general you can find what industries NLP is good at solving problems for. For general web development and some kind a CRUD app, this may not be applicable.

It took a bit of market research to align the two, but once I did it was great. With the idea itself, I just had a few simple metrics:

1\. B2B (I have a raw hate for B2C just due to how much harder they are and it's harder to get a sustainable business off the ground vs businesses that just pay money)

2\. Repeatable revenue source: subscription based services are easy to forecast, and you typically need 3 tiers for a pricing scheme to segment customers.

3\. Ease of validation: Business problems are easy to predict. You have to ask the right questions, but your only real criteria has to be: Does this save the customer money or time? If it does, you only have to survey some different businesses to ensure the idea is wanted by enough of them. Congrats, you have something.

For customer development, just do some google searches in your target niche and start firing off some emails. Better yet: try to find where these customers gather. Whether it be on support forums, or even freelancing market places.

That's how zapier took off if I remember right. In my case, I had a lot of luck with freelancing forums since I'm looking to automate certain tasks that virtual assistants usually do.

A bit of a simplistic explanation, but easy enough to get started. What might work for me might not work for others, but there it is.

</comment><comment><USER4> I'm probably going to be one of many who will say that you should pick a pain you're already having and try to solve it. It's the only way you'll know exactly what to build and how to build it.

The more you try this the easier it will become, and after a few failed attempts you'll know how to get from the "new idea" to a finished product. Yes failed attemps, it'll probably take a while until you learn which things are worth building and which aren't.

Don't be afraid to be very specific. Pick a niche problem, don't try to build a solution that fits everyone. Just go after one specific use case and do it right.

You can try solving someone else's problem, or a problem you see in the company you work for, or a problem your customers are having. But be sure to understand the pain you're trying to solve, feel the pain, you need to know why are you building this thing. Don't just do it because it is cool, do it for a reason.

<comment><USER5> I completely agree with picking a pain that you are experiencing and try to solve it.

In addition to the pluses mentioned above, solving a pain you experience means you will be in a position to "dog-food" your own solution. This is obvious but worth reiterating. If, for example, you solve a problem that people other than you have, then you will not be using your own solution, and this is likely to lead you astray.

Having said that, be careful about being too "niche" or too personal with your solution. After you have come up with a problem you would like to solve for yourself, and you have ideas on how to solve it, go out and ask others: \- do you have this pain? \- how bad is it? \- if someone offered solution X for Y dollars, would you consider it? \- what would be some of the requirements and hangups that will keep you from adopting solution X?

In other words you don't want to solve your pain and then find out nobody else perceived the same pain in the same way. That's a one-way ticket to the deadpool.

</comment></comment><comment><USER6> > I keep thinking "everyone else does that, I probably won't

> bring anything new to the table".

Well if you're going to compete with established players (which is not a bad idea), you have to answer this question.

The good news is that a lot of software is painful to use. When you figure out what you want to make, look at your competitors. Search for "competitor X sucks" and things like that; figure out what people really dislike about using their software. Then make sure your own software doesn't fall into the same traps.

</comment><comment><USER7> How about a groupon but for cruise ships?

<comment><USER7> Why the downvoted? I think the travel industry would benefit froma groupon like service.

<comment><USER8> Isn't Groupon's pitch to the companies that they will get repeat customers? I don't think that industry would really benefit.

</comment></comment></comment><comment><USER9> There have been numerous topics on "I need an idea" so I suggest you to use the search bar at the bottom and to others to NOT dog feed him links to essays et cetera. :-)

<comment><AUTHOR> This is not a "I need an idea". There are plenty of ideas to use. The question is: Why did you pick that specific idea?

<comment><USER9> Then rephrase the thread title and text...

</comment></comment></comment><comment><AUTHOR> So many good answers. Thank you everyone!

</comment><comment><USER10> Disclaimer: Our focus at Fogbeam is on "deploy on premises" apps, not SaaS. And while we expect to offer our software in SaaS form later, it isn't our focus, so my perspective may be a bit skewed.

That said... I feel like you just have to start with something that interests you. In my case, I was just plain fascinated by the _idea_ of "social networks in the enterprise"... I was also really interested in machine learning / artificial intelligence, knowledge management and the idea of "collective intelligence". And over time, different events just led to all the dots starting to connect, and I started to see the kinds of products I wanted to build. Of course, the vision was pretty fuzzy at first, and we've iterated on it, and de-emphasized some aspects, added new aspects, promoted aspects that were originally less emphasized, etc.

The thing is, there are absolutely people already doing some - if not exactly all - of what we're doing. There are "enterprise social network" products out there... hell, there's actually a laundry list of them: Jive Software, Yammer, Hall.com, Tibco Tibbr, IBM Connect, Salesforce Chatter, etc., etc., etc. But, to that point, two thoughts:

1\. Despite how many ESNs there are, we still have some aspects to our approach that are actually different from the other ESN products out there. Our vision also goes bigger than just the ESN... that'll be our first product, but we see it as just part of a much larger whole. And it's that "whole" in sort of the "whole product"[1] sense that we think will _really_ set us apart when it's in place.

2\. Competition doesn't bother us. I remember reading a blog post from Bob Parsons (of GoDaddy fame) a few years ago, that said something like (paraphrased):

 _" Don't be scared of crowded markets, just be better than everybody else"_.

That resonated with me. Call me arrogant, but yeah, we think we can build a better product than Jive, Yammer, Hall, Tibco, IBM, Salesforce or whoever. And we think we're operating with a superior big-picture vision. So basically, we don't care that there's "somebody else doing that", we just intend to beat them.

So I guess if I had any advice for you, I'd say:

Start with something you're already interested in. Look for places where two or more of your interests intersect, or can be combined in such a fashion as to create something novel. Once you have the basic idea in place, do a deep dive into that world... read the literature (if there is any) on the domain in question, talk to people who might be potential users of your product (or, at the earliest phases, anybody who'll talk to you) and solicit their ideas. Look for the "X sucks" forum posts for your competition and see what people are complaining about. There's your opportunity to do better.

Another idea I'm big on could be paraphrased by saying "everything old is new again" or "the only way forwards is backwards". I know I've ranted about this before, but I think there's a ton of value in going back and reading the works of early computer industry pioneers - people like Vannevar Bush, Douglas Engelbart, J.C.R. Licklider, Norbert Wiener, Herbert Simon, Alan Newell, Ted Nelson, Marvin Minsky, etc. and seek inspiration in their writings. Surprisingly, there are ideas that were being batted around in the 1960's (or earlier) that haven't been fully realized yet. Take that inspiration, merge it with your interest area, and see if you can't come up with some ideas for ways to differentiate your product.

Also, watch that Brett Victor video[2] that is posted here on HN quite frequently. It's chock full of amazing insights.

Edit: to add one more thing: I don't know that being passionate about the thing you're building is sufficient (it almost certainly isn't) but I'd almost be willing to be that it is necessary. At the very least, I think it's a huge benefit to you if you're genuinely enthusiastic about the product and would want to use it yourself. In our case in particular, I definitely _want_ to grow a large, profitable, kick-ass company... but even if we fail at that, or even if we weren't even _trying_ to do that, I'd still enjoy the process of creating this stuff, because working on it is genuinely enjoyable to me. And when the hours start getting long, and things aren't going your way, and some doubt creeps in, I believe it's a lot easier to keep moving forward when that's true. If you do something that's _only_ about the money, I would question if you'll be motivate enough to power through the inevitable tough periods.

[1]: [http://en.wikipedia.org/wiki/Whole_product](http://en.wikipedia.org/wiki/Whole_product)

[2]: [http://vimeo.com/36579366](http://vimeo.com/36579366)</comment>


Picat – a logic-based multi-paradigm programming language - <AUTHOR> http://www.picat-lang.org <comment><USER2> Congratulations for the code examples on the home page. Not every language designer does that. Plenty of examples on HN.

My only criticism is about dots and commas, and I know where they come from. Especially as

> Picat, as a scripting language, is as powerful as Python and Ruby.

But I'm not adding commas and dots to the end of each line, it's a little nightmare. I'm staying with Python and Ruby for scripting.

Is there really no way for logic programming languages to skip commas and dots or is it only a tradition?

<comment><USER3> The commas and dots are operators, not syntax.

one, two, three.

Is essentially compiled down to:

if (one && two && three) { return three; }

Whereas

one, two, three;

one, four.

compiles down to:

if (one && two && three) { return three; } else if (one && four) { return four; }

So yeah, it's not syntax.

, === &&

; === ||

. marks end of a condition, so } in C.

<comment><USER2> The script is

      import util.

      input_data(Tri) =>
        Lines = read_file_lines("triangle.txt"),
        Tri = new_array(Lines.length),
        I = 1,
        foreach(Line in Lines)
            Tri[I] = Line.split().map(to_integer).to_array(),
            I := I+1
        end.

In the mind of an imperative scripting developer those commas are (useless) semicolons.

I wrote a little Prolog some 30 years ago. Probably those commas and dots have the same function, logic and, as you write.

I understand that it's a core feature of the language, but its really awkward when using Picat imperatively. I've seen this dynamic of obeyibg to tradition in many languages. The vast majority of developers are used to imperative languages. If designers of functional, logic, etc languages want to hijack those developers to their own language they could try to be creative and bold and give those developers a syntax their are familiar with.

Elixir has a Ruby like syntax to Erlang and had some success at onboarding Ruby developers. But it wasn't bold. Example: they didn't have courage to turn GenServer into a Class with a CPU. It's still a bag of functions, partly called by clients, partly called by the server, with method names (if it was a class) hidden in arguments and explicit state management.

The Reia language was a bolder attempt but unfortunately its designer liked Elixir and killed his project. My guess: there would be many more Reia developers than Elixir ones by now.

[http://reia-lang.org/](http://reia-lang.org/)

<comment><USER4> I changed all the commas to "and"'s" and the dots to ";"'s (except in a.b statements):

      import util;

      input_data(Tri) =>
        Lines = read_file_lines("triangle.txt") and
        Tri = new_array(Lines.length) and
        I = 1 and
        foreach(Line in Lines)
            Tri[I] = Line.split().map(to_integer).to_array() and
            I := I+1
        end;

Is that better?

<comment><USER2> No. My point is that language designers should try to implement different paradigms with mainstream syntax. This if they are interested in making their languages mainstream, which might not be their goal.

The script should do without the ands, the commas and the colons. The end of line should be the and, or what the language understands to be the end of a statement.

By the way, the dot or the semicolon after the end look really redundant.

<comment><USER4> >> The end of line should be the and, or what the language understands to be the end of a statement.

The problem with that is that the "," is there not to separate statements ("literals") but to declare a relation between them, specifically, conjunction.

Conjunction is one relation that you may way to declare between literals. There is also disjunction and implication. So you do need something to separate "A and B" from "A or B" and "A if B".

You say- "use whitespace for the and". OK. But then, what about the "or" and the "if"? And if we use special symbols for the "or" and the "if" then what's the point of not using one for the "and" also?

As to "block" delimiters, like "." or ";" etc. As far as I can tell the only languages that do not have "block" delimiters are the kind you can find on [https://esolangs.org/wiki/](https://esolangs.org/wiki/), and that is for reasons of a) readability, actually and b) convenience in compiler writing.

</comment></comment></comment></comment></comment></comment><comment><USER5> Is it just me, or is there an uptick in boutique programming language posts on HN lately? Not complaining, just curious if anyone else has noticed.

<comment><USER6> I'd say it's a general trend in industry, similar to that in the 80's with their fourth generation languages.

It happens when the current programming languages fail short of solving the most difficult problems the industry faces and programmers explore some paradigms that solve them nicely, but those paradigms haven't been integrated into a single coherent platform.

This shift is pretty much happening with reactive functional programming - which solves asynchronous calls in the web -, and to some extent with large- scale module composition, which still lacks a good widely known solution.

</comment></comment><comment><AUTHOR> A previous submission on Picat: [https://news.ycombinator.com/item?id=16563349](https://news.ycombinator.com/item?id=16563349)

Not sure why the older posting wasn't picked up when I submitted the link.

<comment><USER7> because it was "a long time ago"

</comment></comment><comment><USER8> I won't know who Hakan Kjellerstrand is, but if you quote him you should either put [sic] following "suites" or put [suits] instead of it. Gives a bad impression straight off the bat. You could argue language is different from programming but to my subconscious mind it speaks of a lack of attention to detail and excellence.

<comment><USER9> If you search for constraint programming examples on the internet, you will eventually end up on his web page.

</comment></comment><comment><USER10> There are functional languages which have logic programming libraries.

</comment><comment><USER10> Really bad idea... please no imperative

<comment><USER11> Actually I see all the non-imperative ways as lost time in software development. At some point we will realize that people think imperatively.

<comment><USER12> Software developers who are taught imperative programming are used to translating their high-level, human thoughts into imperative instructions telling the computer exactly what to do to make the answer they want.

With functional programming, one is able to translate thoughts more directly. Non-programmers actually have an easier time with functional concepts like mapping than for loops, non-local mutation, etc.

At any rate, imperative languages have a legacy of frankly buggy, shitty software. As programs get larger and more concurrent, this problem is getting much, much worse. That's why functional(ish) libraries like Redux are so popular. They can help tame this complexity.

Imperative programming absolutely has its place in certain situations like systems or numerical programming, but it is a poor tool for most things people program. Rust, I think, is imperative programming done right. While it's a bit confusing with all the pointer types, it has the tools needed to safely mutate, etc.</comment></comment></comment>


Elon Must Worried That Google Might Accidentally Build SkyNet - <AUTHOR> http://mashable.com/2015/05/12/elon-musk-fears-larry-page/

<comment><USER2> Not the first time Elon Musk has underestimated how complicated and hard AI actually is: [https://news.ycombinator.com/item?id=9235002](https://news.ycombinator.com/item?id=9235002)

</comment><comment><USER3> AI is not that smart yet to reach self awareness and know the difference between good and evil.

Terminators are still a work of fiction. AI is still primitive and we don't have genuine intelligence or anything at a human level of intelligence.

The real threat from AI is taking away jobs from human beings. To counter that there would have to be some sort of universal basic income and low cost housing and low cost college education to get back into better paying jobs that require more knowledge to work for those who got replaced with an AI program or robot.

<comment><USER4> However it's not required for AI to distinguish good and evil to be harmful. It could be the very lack of this distinction that enables it to interpret a situation where the selected course of action is destructive to humanity.

<comment><USER5> Exactly! A traffic-control AI could change lights more quickly and efficiently to encourage streams of cars to go faster, and optimize for total volume. Never mind a few more people die each day.

<comment><USER3> Not to mention that the AI lacks common sense to notice that people are dying due to its decisions and make corrections so that they don't die.

We are so reliant on technology and software to make decisions for us, and none of it is based on common sense.</comment></comment></comment></comment>


A Woman Who Makes Prosthetic Pinkies for Ex-Yakuza Members - <AUTHOR> http://motherboard.vice.com/read/the-woman-who-makes-prosthetic-pinkies-for-ex-yakuza-members <comment><USER2> From the article: 45% of members have at least one part of a digit amputated. Those are probably not stats they tell you on recruitment day!

<comment><USER3> It also seems a bit of a defeating cycle. If you lose part of your pinky, you are, almost by definition, less effective than you were before (with the exception of maybe running), thus leading you to make more mistakes.

I get tradition, but you have to wonder if 45% of your people are operating at 99% of their capability, that's quite a bit of lost manpower.

<comment><USER4> That's one way to look at it. You could also see it as 45% of your workforce has now a much greater difficulty finding a normal job because of this now visible gang affiliation. Those 45% have less options to make a traditional living which increases their reliance on the Yakuza.

</comment></comment></comment><comment><USER5> That lady would certainly have a lot of interesting people owing her favours. ;)

</comment><comment><USER6> so most of these pinkies are cut by the yakuza members by themselves after some offense. Like one guy got drunk driving his boss's car alone and crashed it.

Considering how much the Yakuza pulls in (billions), I'd thought they could write it off as a business expense. But nope, the young Yakuza employee had to cut off his finger and exit the company. No severance or pensions or benefits.

[https://www.youtube.com/watch?v=Jmp8_PAej3c](https://www.youtube.com/watch?v=Jmp8_PAej3c)

I think that in some ways this is actually very effective because instead of killing your underlings for fucking up or offending you, you have them mutilate a part of them but little at a time to not ruin their productivity or affect their job. Which explains why ex-Yakuzas have different digit count...

And let's face it their industry is largely underground with no enforcement from the government due to being declared illegal. Nobody would do their jobs seriously if there wasn't some kind of morbid air of fear in the work atmosphere. Your underlings wouldn't take your orders etc. Killing them is tough because recruitment is much tougher in Japan, unlike America where gangs thrive. Young people in Japan are starting their own gangs now and don't like the rigid culture of the Yakuza.

[https://www.youtube.com/watch?v=jw_ICAAFoiM](https://www.youtube.com/watch?v=jw_ICAAFoiM)

Imagine if your startup made a policy that you had to pay $1000 in cash each time you made a mistake, how scary is that?

<comment><USER7> The interesting thing about the yakuza is that, in Japan, they're not actually illegal. The activities they partake in are, but actually being a yakuza member isn't a crime.

<comment><USER6> they are cracking down on it now I think with the equivalent of RICO act making it easier for police to search yakuzas...but face it, Japanese police are more on the quirky side and yakuzas seem to not take them seriously and harassing them.

[http://www.mirror.co.uk/news/weird-news/japanese-robocop- tra...](http://www.mirror.co.uk/news/weird-news/japanese-robocop-train-bosses- recruit-3181592)

</comment></comment></comment><comment><USER8> How are pinkies not "regular prosthetics"? Yakuza ex-members are just humans.

</comment><comment><USER9> These might be good for Emacs users too.

<comment><USER10> Nah, I'm naturally growing an extra pinky for pinky-mode.

Hum, that makes me think about some interesting ideas. Would be needed a frodo-mode in emacs for disabled people? Can you still be efficient with a computer with a fake finger?

<comment><USER11> Real emacs power-users can also consider _foot-pedals_.

(No, I'm not joking.)</comment></comment></comment>


Why iOS7 was a bad move - <AUTHOR> https://medium.com/apple-computer/56f5586c192e

<comment><USER2> "Flat UI was super hot months before Apple has used it and that's rarely happened before."

One problem is Apple's yearly release schedule. This allows other companies to innovate while Apple is still waiting months for their next scheduled release.

<comment><USER3> There were smartphones years before the iPhone, even ones with touchscreens and no keyboard. There were tablets decades before the iPad. There were online application market places years before the App Store. Apple doesn't often do anything first, they just do it 'right', and that means taking time and thinking it through.

<comment><AUTHOR> That's rather my point. I don't think they have done 'flat' right. Plus, what exactly is Apple-esque about the flat design in iOS7?</comment></comment></comment>


Elm: The Pragmatic Way (new course for Elm 0.18) - <AUTHOR> https://pragmaticstudio.com/elm <comment><USER2> I found Pragmatic Studio's original Elm tutorials extremely helpful when I started using Elm. I'm glad to see this update from Mike and Nicole.</comment>