3 ms·

Successful software companies are mostly founded by software engineers, or at least other white collar professionals They're also founded by people that know t

Successful software companies are mostly founded by software engineers, or at least other white collar professionals They're also founded by people that know the business they're dealing with. If you know oil and aviation, think about where customers are feeling pain and focus your effort there.

byoung2 7y ago
They're also founded by people that know the business they're dealing with I worked as a contract software engineer and I built quite a few MVPs for niche businesses I would never have thought of. I built a dashboard for rental management companies to track vendors (e.g. plumbers, electricians, pool cleaners) to make sure their licenses, insurance, and background checks are up to date. I built a tool for companies to track and calculate multistate tax withholding for traveling employees (apparently there is a complex algorithm based on the number of days you worked in the state, your home state, etc). There are thousands of these business ideas out there that some domain expert is running in a spreadsheet but could be turned into a SaaS product.
- joezydeco 7y ago
  I worked as a contract software engineer Did the domain knowledge come from the person paying you, or did you figure it out yourself?
  - byoung2 7y ago
    The client supplied the domain knowledge...in more than a few cases they were doing things manually, and I automated them. For example the vendor verification involved manually looking up licenses, or doing data entry on ACORD25 insurance forms. I automated it, so that given a license number, trade, and state, a crawler would fetch the data on a schedule. I also wrote a parser that could read insurance data from an ACORD25 form and put it in a database. The client was tracking all of this in spreadsheets, and I just copied the logic from there.
    - deleted 7y ago
      [deleted]
travisjungroth 7y ago
That's where my main focus is right now. I want to push it out just a bit further. The best outcome of this thread for me is someone mentions something that I have a connection with (maybe friends with an expert I could get involved) that I didn't even think of.
- wenc 7y ago
  I get what you're trying to do. Let me also suggest something different -- instead of tackling things from the solution end (software), why don't you immerse yourself into a few verticals (in whatever ways you can -- job, conference, connections, etc.) to really understand the unsolved problems without presuming a software solution? Don't be afraid to work on problems where the solution might not be a software solution. Also you need to have experienced the problem yourself in order to have skin the game. (This was one of the take-aways from an IDEO design thinking workshop I attended — you have to find ways to empathize with the user you’re designing for) Chances are a software solution will likely emerge anyway (in this day and age, everything runs on software), but by focusing on solving the problem, you ensure your solution has value, and you're not just trying to find a use case to write software for. Understanding the problem domain prior to presuming the solution space almost always works better than the other way around. (speaking as someone who has tried the approach problems from both ends in a non-tech field) The latter usually results in products that have no flair and no market uptake. Tobi Luetke started out trying to sell snowboards on-line but didn't find any suitable eCommerce software so ended up writing what eventually became Shopify.

byoung2 7y ago

They're also founded by people that know the business they're dealing with I worked as a contract software engineer and I built quite a few MVPs for niche businesses I would never have thought of. I built a dashboard for rental management companies to track vendors (e.g. plumbers, electricians, pool cleaners) to make sure their licenses, insurance, and background checks are up to date. I built a tool for companies to track and calculate multistate tax withholding for traveling employees (apparently there is a complex algorithm based on the number of days you worked in the state, your home state, etc). There are thousands of these business ideas out there that some domain expert is running in a spreadsheet but could be turned into a SaaS product.

joezydeco 7y ago
I worked as a contract software engineer Did the domain knowledge come from the person paying you, or did you figure it out yourself?
- byoung2 7y ago
  The client supplied the domain knowledge...in more than a few cases they were doing things manually, and I automated them. For example the vendor verification involved manually looking up licenses, or doing data entry on ACORD25 insurance forms. I automated it, so that given a license number, trade, and state, a crawler would fetch the data on a schedule. I also wrote a parser that could read insurance data from an ACORD25 form and put it in a database. The client was tracking all of this in spreadsheets, and I just copied the logic from there.
  - deleted 7y ago
    [deleted]

travisjungroth 7y ago

That's where my main focus is right now. I want to push it out just a bit further. The best outcome of this thread for me is someone mentions something that I have a connection with (maybe friends with an expert I could get involved) that I didn't even think of.

wenc 7y ago
I get what you're trying to do. Let me also suggest something different -- instead of tackling things from the solution end (software), why don't you immerse yourself into a few verticals (in whatever ways you can -- job, conference, connections, etc.) to really understand the unsolved problems without presuming a software solution? Don't be afraid to work on problems where the solution might not be a software solution. Also you need to have experienced the problem yourself in order to have skin the game. (This was one of the take-aways from an IDEO design thinking workshop I attended — you have to find ways to empathize with the user you’re designing for) Chances are a software solution will likely emerge anyway (in this day and age, everything runs on software), but by focusing on solving the problem, you ensure your solution has value, and you're not just trying to find a use case to write software for. Understanding the problem domain prior to presuming the solution space almost always works better than the other way around. (speaking as someone who has tried the approach problems from both ends in a non-tech field) The latter usually results in products that have no flair and no market uptake. Tobi Luetke started out trying to sell snowboards on-line but didn't find any suitable eCommerce software so ended up writing what eventually became Shopify.