Can you walk me through the thought process of why a competitor existing means you abandon this idea? Are they so central to your industry that they can immediately lock up 100% of the market? Are they going to be cross-selling from something which is more widely distributed in your niche than say Quickbooks or Microsoft Office?
Don't compete on price. Enterprise customers care about it a lot less than you do, and enterprise customers are not motivated to purchase by "We saved a few thousand bucks and I lost my job because the deployment blew up in our face." I'd be far more worried about that sales objection than the existence of a competitor.
You can probably compete on many other axes. One of my competitors has 400 employees, at least 20 of whom answer phones with customer questions. I have 0 employees, intentionally don't have a routable phone number, and self-assess at mediocre in terms of responsiveness to email. And I win sales dogfights with that company, occasionally, because prospects believe I'll offer them better CS. (The winning argument, which I've stolen fragrantly from Jason Cohen, is "You can call them up at any hour, day or night, and instantly speak to someone who can't solve your problem. Or you can drop me an email, and it may take me two days to get to it, but your email will always be answered by the guy who built the system with his own hands. Your call who you want in charge of your questions when it is your business on the line.")
There are other options, such as competing on market segmentation. Your competitor, for example, might serve primarily a healthcare market. If the same need exists outside of healthcare, you can target your marketing/development over there, and make a product which really sings for those other audiences. Is their product generic? Make yours hyper-specific. Is their product hyper-customized? Make yours the "It only does 10% of what the other guy does, but it is the right 10%, and it actually works out of the box."
How do they market/sell it? Is it one of those "Ask for a quote and we'll let you speak to a sales rep?" type of deals. Consider selling via a lower-touch sales model. Worse comes to worse, you learn why high-touch sales is so darn popular.
Also, to impart on you as early as possible the Voice of Pained SaaS Founder Experience: pause building for a moment and verify that you can successfully sell this. If necessary, you can have mockups or a minimally functional prototype to support the sales conversation. There are many worthwhile SaaS products which cannot be sold by a single founder into particular enterprises, so knowing whether your product is saleable or not given your constraints is a useful sanity check on whether to spend the rest of the schedule building it out.
Selling SaaS which doesn't exist is fairly straightforward. Find a customer. Ask them to buy it. Note why they tell you "No." Adjust until you have gotten a "Yes." Now, repeat at least 5 times. Then, finish building it.
If you cannot find a customer, or you can find the customer but can't get the right decisionmaker internally to get the time of day, or your customer doesn't consider this a hair-on-fire priority, or your current conception of the product doesn't match things they budget for, or any of a thousand other things systematically happen to block sales, then building the software does not in itself cure those sales problems.
Incidentally, the number of enterprise deals which you have to close to have a very good living as a solo founder is somewhere between one and twenty. Their billion dollar valuation might be sustained by a team of stab-their-own-mother-for-a-commission-check reps being fed the Glengarry leads from the best marketing operation in enterprise software, but even they don't win every deal. Table scraps are delicious if the table is very big relative to the dog.
A bit of background, I've been working in environments next to, and sometimes with, large scale Semantic Graph projects for much of my career -- I usually try to avoid working near a semantic graph program due to my long histories of poor outcomes with them.
I've seen uncountably large chunks of money put into KM projects that go absolutely nowhere and I've come to understand and appreciate many of the foundational problems the field continues to suffer from. Despite a long period of time, progress in solving these fundamental problems seem hopelessly delayed.
The semantic web as originally proposed (Berners-Lee, Hendler, Lassila) is as dead as last year's roadkill, though there are plenty out there that pretend that's not the case. There's still plenty of groups trying to revive the original idea, or like most things in the KM field, they've simply changed the definition to encompass something else that looks like it might work instead.
The reasons are complex but it basically boils down to: going through all the effort of putting semantic markup with no guarantee of a payoff for yourself was a stupid idea.
You can find all kinds of sub-reasons why this was stupid: monetization, most people are poor semantic modelers, technologies built for semantic system generally suck and are horrible (there's pitifully few reasoners built on any kind of semantic data, turns out that's hard), etc.
For years the Semantic Web was like Nuclear fusion, always just a few years away. The promise was always "it will change everything", yet no concrete progress was being made, and the vagueness of "everything" turned out not to be a real compelling motivator for people to start adding semantic information to their web projects.
What's actually ended up happening instead has been the rebirth of AI. It's being called different things these days: machine learning, heuristic algorithms, whatever. But the point is, there's lots of amazing work going into things like image recognition, context sensitive tagging, text parsing, etc. that's finding the semantic content within the human readable parts of the web instead. It's why you can go to google images and look for "cats" and get pictures of cats.
Wikipedia and other sources has also started to look more structured than it previously was, with nice tables full of data, these tables have the side benefit of being machine AND human readable, so when you look for "cats" in google's search you get a sidebar full of semantic information on the entity "cats": scientific name, gestation period, daily sleep, lifespan, etc.
Like most things in the fad driven KM world, Semantic Web advocates are now simply calling this new stuff "The Semantic Web" because it's the only area that kind of smells like what they want and is showing progress, but it really has nothing to do with the original proposal and is simply a side-benefit of work done in completely different areas.
You might notice this died about the same time "Mashups" died. Mashups were kind of an outgrowth of the Semantic Web as well. One of the reasons that whole thing died was that existing business models simply couldn't be reworked to make it make sense. If I'm running an ad driven site about Cat Breeds, simply giving you all my information in an easy to parse machine readable form so your site on General Pet Breeds can exist and make money is not something I'm particularly inclined to do. You'll notice now that even some of the most permissive sites are rate limited through their API and almost all require some kind of API key authentication scheme to even get access to the data.
Building a semantic web where huge chunks require payment and dealing with rate limits (which appear like faults in large Semantic Networks) is a plan that will go nowhere. It's like having pieces of your memory sectioned off behind tolls.
"This simple idea, however, remains largely unrealized."
There's a group of people I like to call "Semanticists" who've come to latch onto Semantic graph projects, not as a technology, but as a religion. They're kind of like the "6 minute ab" guy in "There's Something About Mary". They don't have much in the way of technical idea, but understand the intuitive value of semantic modeling, have probably latched onto a specification of some sort, and then belief caries them the rest of the way "it'll change everything".
But they usually have little experience taking semantic technologies to successful projects (success being defined as not booting up the machine and loading the graph into memory, but actually producing something more useful than some other approach).
There's then another group of Semanticists, they recognize the approaches that have been proposed have kind of dead-ended, but they won't publicly announce that. Then when some other approach not affiliated with the SW makes progress (language understanding AI for example) will simply declare this new approach as part of the SW and then claim the SW is making progress.
He wrote this in 2001, and the issues he talks about still haven't been addressed in any meaningful way by professionals working in the field, even new projects routinely fall for most or all of these problems. I've seen dozens of entire companies get formed, funded and die without addressing even a single one of these issues. This essay is a sobering measuring stick you can use to gauge progress in the field, and I've seen very few projects measure well against any of these issues.
Semanticists, of both types, are holding the entire field back. If you are working on a semantic graph project of any kind and your project doesn't even attempt to address any of these things through the design of the program (and not through some policy directive or modeling process) you've failed. It's really hard for me to believe that we're decades into Semantic Graph technologies and nobody's bothered to even understand 2.5 and 2.7.
If your plan to fix problems you're experiencing with your project, the reason it isn't producing useful results, is to "continue adding data to it" or "keep tweaking the semantic models" you've failed.
The goal of the tool "strings" has always been to dump the strings table of a binary object. It happens to also have a mode that lets you try to find random strings-like content in any file. It happens to default to this mode if it can't parse the file as an executable. People thereby have gotten somewhat used to using this tool to having this functionality at hand, and use this tool a lot of this purpose.
This is not, however, the actual goal or purpose of this tool. The fact that many people use Perl as nothing more than a slightly better version of sed doesn't mean that Perl's ability to write complex object-oriented software is "over-engineering". You just don't know what this tool is actually for, which is OK, but means you can't judge whether or not it is "over-engineered".
BSD, apparently going back to at least BSD 4.3, also had a strings tool, and it did the exact same thing: it parsed binary files to dump their strings table. Apple's strings tool has no code heritage from the GNU version, instead being a vague descendent of the one from BSD 4.3. This is how this tool has always worked: stop being part of the noise trying to turn this into a GNU-bash fest :/.
There's another option. While doing the interviews, and preparing to GTFO, just go back down to 40 hours. Slow down. Increase code quality. And intentionally miss your deadlines.
This is something you can only do when things are crazy and out of control, and everyone else is leaving. You see, they cannot fire you because they cannot hire anyone to come in. Thus, you doing any work is better than having noone.
Make sure to communicate that these won't be done. Tell them that they need to make contingency plans and give them your own schedule of reasonable dates. (Of course, you need to make sure to make these dates.)
If they bring you in for discipline, play the health card. "Health is something you cannot pay enough for me to exchange. I started having major health problems, and they were stress related. I cannot meet the given dates, and I am communicating that. It is your job to manage client expectations as a manager."
The current climate for programmers means that you can do this right now.
I'm stealing one of the YouTube comments, because I actually thought it was pretty interesting. I started watching this thinking the interviewer was an idiot, but I think the issue is a little more complicated than it seems at first. Comment from YouTube user "tapo":
So in the 90's Sun Microsystems created Java, which has two components, the programming language and the runtime. The runtime (the Java you install) lets you run things written in Java on any device regardless of OS or CPU architecture. Write once, run anywhere. This was a huge threat to Microsoft. Why write Windows programs when you could write Java programs and they'd run on any computer?
So Microsoft wrote their own Java runtime called the MS JVM, and made it part of Windows, it extended Java to do Windows-only things, meaning there were now "Java" apps that could only run on Windows, destroying the whole point of Java.
This became part of the antitrust trial because it ruined Sun's product. In a separate case, Sun sued Microsoft and won.
Don't compete on price. Enterprise customers care about it a lot less than you do, and enterprise customers are not motivated to purchase by "We saved a few thousand bucks and I lost my job because the deployment blew up in our face." I'd be far more worried about that sales objection than the existence of a competitor.
You can probably compete on many other axes. One of my competitors has 400 employees, at least 20 of whom answer phones with customer questions. I have 0 employees, intentionally don't have a routable phone number, and self-assess at mediocre in terms of responsiveness to email. And I win sales dogfights with that company, occasionally, because prospects believe I'll offer them better CS. (The winning argument, which I've stolen fragrantly from Jason Cohen, is "You can call them up at any hour, day or night, and instantly speak to someone who can't solve your problem. Or you can drop me an email, and it may take me two days to get to it, but your email will always be answered by the guy who built the system with his own hands. Your call who you want in charge of your questions when it is your business on the line.")
There are other options, such as competing on market segmentation. Your competitor, for example, might serve primarily a healthcare market. If the same need exists outside of healthcare, you can target your marketing/development over there, and make a product which really sings for those other audiences. Is their product generic? Make yours hyper-specific. Is their product hyper-customized? Make yours the "It only does 10% of what the other guy does, but it is the right 10%, and it actually works out of the box."
How do they market/sell it? Is it one of those "Ask for a quote and we'll let you speak to a sales rep?" type of deals. Consider selling via a lower-touch sales model. Worse comes to worse, you learn why high-touch sales is so darn popular.
Also, to impart on you as early as possible the Voice of Pained SaaS Founder Experience: pause building for a moment and verify that you can successfully sell this. If necessary, you can have mockups or a minimally functional prototype to support the sales conversation. There are many worthwhile SaaS products which cannot be sold by a single founder into particular enterprises, so knowing whether your product is saleable or not given your constraints is a useful sanity check on whether to spend the rest of the schedule building it out.
Selling SaaS which doesn't exist is fairly straightforward. Find a customer. Ask them to buy it. Note why they tell you "No." Adjust until you have gotten a "Yes." Now, repeat at least 5 times. Then, finish building it.
If you cannot find a customer, or you can find the customer but can't get the right decisionmaker internally to get the time of day, or your customer doesn't consider this a hair-on-fire priority, or your current conception of the product doesn't match things they budget for, or any of a thousand other things systematically happen to block sales, then building the software does not in itself cure those sales problems.
Incidentally, the number of enterprise deals which you have to close to have a very good living as a solo founder is somewhere between one and twenty. Their billion dollar valuation might be sustained by a team of stab-their-own-mother-for-a-commission-check reps being fed the Glengarry leads from the best marketing operation in enterprise software, but even they don't win every deal. Table scraps are delicious if the table is very big relative to the dog.