In my own SMB, I still self-host git, CI, chat, etc. I love the privacy and control, but I also needed to open these services to remote workers without exposing them to the world. So I built an appliance to protect my internal web apps by requiring user/pass+yubikey at multiple layers of the stack: L3 (p2p vpn), L4 (mTLS), and L7 (OIDC). The appliance is self contained (VPN, LDAP, NTP, CA, OIDC), like a classic domain controller, and it keeps servers safe from any users without an authorized hardware key.
I'd love to bundle this with an admin panel and sell it, but I forsee problems connecting with the right market:
* Clients who have meaningful IT budgets will require inter-operation with their legacy domain controllers. This means I won't have an MVP without major changes and lots of testing. It also puts my own product at risk: if Microsoft doesn't want to support my integrations, they can disable my product with a software update.
* Clients who are too small to have lots of legacy IT requirements will have small budgets and require lots of support. Some of these clients will grow larger, but this is a long game. I would love to support these clients but don't want to die for lack of revenue in the short term.
How would you sell what I've built?
So like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems.
I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future.
Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration.
In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.
- certificate management amongst a plethora of hosts, both SSL/web certificates for external use, and management and installation of self-signed "root" certs for validating internal applications and services - keymastering server: an appliance that acts as a genuine root of trust for an organization, using a Yubico HSM for key storage, but providing middleware & admin controls to manage issuance and distribution of intermediate certificates - AD/LDAP/SSO/etc user management, key issuance, etc.
If you have a small team and you don't need global redundancy for these functions across a large fleet, then it makes a lot of sense IMO to shell out $5-10k for a set it and forget it security appliance that makes certificate/key management simple and easy.
I think the biggest challenge is that it's hard to build trust as a startup without open-sourcing your stack, but that makes it a lot harder to get buy-in for an appliance model unless you have some creative dual-licensing ideas.
But "your keys/certs are stored securely on your hardware in the room next door" is a compelling value proposition & probably a much easier pill to swallow for certain companies than a cloud HSM or other solutions which sorta boil down to "trust me bro".
> a compelling value proposition
I completely agree; I'd originally drawn up a design for an offline root CA, then an box with a separate server for an intermediate CA with HSM for intermediate keys, a second, dedicated Secure NTP server (possibly hardware based) so that certificate expiration times could be kept short.
While all that is easy enough to prototype, the complexity of hardware distribution is better left to a later point in the roadmap.
A hardware HSM is not magic or even especially complex. Java cards can do it (slowly). Yubikeys can do it. Other vendors’ devices can do it. Lots of microcontrollers can do it as long as you don’t need resistance to complex physical attack. A startup in this space should seriously consider building its own.
I am not the market for the OP. Because I want the ability to change MFA vendors or federate, but the strategies of non-software companies is much different IMHO.
Companies fail, projects degrade, like lask week quality can go down.
The better question is why would my organization couple their success to you wagon, do you provide them with a way to get their info out in a portable way?
But there are many reasons to maintain the ability of your IAM to access multiple IDPs.
I do think there is a growing market for products that don't use your private data for their own goals.
But coupling a domain controller to a single 2FA provider just doesn't have any value as you have described it, at least for me.
I am not the entire market, just one potential user, so take this as feedback and not outright dismissal.
Perhaps if you develop the idea more I may be interested in the future.
Like, I was looking for an RFID entry system for a customer. Some of these are advertised as using DES/AES security (implied to be some version of DESfire). Most aren't. Try figuring out if they actually use DESfire and if the handshake is tunneled to the door controller (placed in a secure area) or the card reader (placed in the vulnerable, insecure area) has the keys and is just sending the UID to the controller. Nobody will answer this question. (Presumably because these secure systems are all actually UID-only on the backend so trivial to bypass if you learn a valid backend UID).
And even then, you're like "Okay, this sounds interesting. I wanna buy it." - "Oh, you can't. We don't sell these. You need a system integrator / installer." And then you go to one of these and it's super obvious they have essentially no clue how any of the stuff they're system-integrating works, but of course they won't give you admin access to the system they wanna install. "How do I configure this?" - "You don't. Only we do. Using a proprietary software." - "Where's the system manual for this?" - "We have it, we can't and won't give it to you."
I mean a lot of stuff works like this, usually with incompetent middle-men fucking up products which aren't all that bad (another most popular example would be HVAC and heat pumps, especially ASHPs) and manufacturers trying to make a SaaS kind of play with hardware you bought. But for security it feels especially egregious. How do you know the installer doesn't have a master key? Well, they usually do. How do you know the ACLs are set up correctly? Trust me bro. And so on.
None of this was done. It was out in the sun (laminate on control panel fused to the screen), air intake was factory sealed (system failed after a while) and it was left in the rain after an installer came to remove the covers (air intake / exhaust are top facing).
I could have easily solved the issues myself but didn't want to give them the option of pinning liability on the client.
What use case + benefit would folks have using this? Why should they trust you?
A classic DC would authenticate windows logins and rely on an external network. My design authenticates just TLS and web-app logins (not windows) but also provides an authenticated layer 3 network. So it's hardware-attested zero trust -- something that's difficult to securely assemble out of existing SaaS.
This would be overkill for a typical call center (large scale, high churn, low trust) but perfect for a team working on sensitive IP (smaller scale, low churn, high trust.) Research and development, administrating expensive systems (regional manufacturing?) or for collaborative work on sensitive documents (legal?)
Think Tailscale+Let's Encrypt+Okta but all in a single package.
1. The market that needs this will not be capable to use it
2. The market that is capable to use it is also capable to use something like Cloudflare Access.
As for 'domain controller', like others have posted, that is a product or branded product from microsoft that doesn't have much to do with what you described. You could argue that Microsoft Windows Server can host most of those services, and will likely need a Microsoft Active Directory service (which in turn requires at least one Active Directory Domain Controller), it's not really related to what you are doing besides perhaps a user directory.
In a way, your product would address the classic setup that Microsoft (and Apple) have thrown away (many) years ago, companies are very bad at IT, and it gets worse as you focus on smaller companies and companies where IT is rather far removed from their core business. Something that is managed and maintained by someone else, that is where the money is, and in almost all cases that means the services and applications are not co-located in some office somewhere, mostly because the office is pretty much irrelevant these days.
I acknowledge this trend; Microsoft wants everyone in the cloud so their on-prem offerings, while entrenched, are stagnant. This could be an opening that lets me build a quality product for a modest customer base who are unable/unwilling to migrate.
Keep in mind that those brands also have connectivity, filing, user directories, network services (DHCP, NTP, NTP, L2 and L3 VPNs), but in practise they suffer from the same things small businesses have for decades: lack of internal knowledge. And since such systems are never set-and-forget, they would either need physical maintenance contracts (which SMBs can't afford) or remote SaaS-style maintenance which somewhat defeats the point.
The gap between people able to buy an appliance and people who know basic routing, DNAT and subnetting is really really big these days, and that's just to get things up and running. The next step up is still bigger gap than it used to be, but also quickly gets you into too-capable-to-be-a-market territory.
Maybe a better model is the one attempted by the private computing brands, I don't know a successful one of the top of my head but they generally have a NUC-like device with Linux on it with hardware root-of-trust and they present it as a portable-but-desktop computer that comes with a more trustworthy OS and network security. Some are based on heads & tails, others on Qubes OS, others just a fork of PostmarketOS with some Graphene in the mix. The early ones all failed because they just weren't useful to the average user, but the later ones didn't fail immediately while they were news.
This is a major advantage of the mesh VPN layer. If your bare metal hosts/guests hardware have internet access via plain old DHCP, they can connect to the mesh network which is where all the special networking happens at the direction of the controller. On the mesh, every node can have a persistent static IP and dns entry, simplifying the network topology for the layers above.
From what I can tell you, good security is hard - we have prepared the product exactly as you describe on various levels (vpn, identity, SSO, Yubikey provisioning, etc) and prepared the architecture to be secure (multiple segments support: intranet, DMZ, proxy for exposing only public endpoints and functionalities publicly)…
What I observe in a year of the project being public and analysing heavily the landscape, similar projects, Reddit of what users are seeking and what problems they have is that: a lot of people and companies value comfort more then security (even if they will not admit it publicly), because security is hard. That also means there is w niche and need, but… it’s really hard to build a secure, easy to use and deploy security system…
Hope you don’t give up and peruse!, as it’s worth fighting about security and privacy
I could see recommending this product to others!
You have a few features that surprised me, like support for "authentication with crypto software and hardware wallets". This seems like the sort of thing a business would never need. Did you have users agitate for this feature? Or is it a direction you're trying to steer clients?
Overall, nicely done, I wish I'd known about this when I started!
Can you share your roadmap? Ideas? Seems we share the same mindset and vision, would be great to exchange knowledge, ideas…
Cheers, Robert
Saying you don't care about your user safety is actually often more costly than pretending you care, and then having a breach.
Unlike YubiKey they sell a wider range of products, such as secure hardware. It seems if you make it work with NitroKey they might be able to sell it as a bundle.
Probably won't hurt to reach out to them as a potential partner
Also, the cheap Nitrokey FIDO2 key doesn't support ED25519 for SSH keys, only RSA and ECDSA, and even though they are open source, the promised support for ED25519 is still not delivered even after 4 years, so I doubt it will ever come: https://github.com/Nitrokey/nitrokey-fido2-firmware/issues/3...
Ultimately, while I like the idea of open-source, for a company use case, we had to go with Yubikey.
It's interesting. You have built something tightly coupled ("like a classic domain controller") but then it is interacting with inspecific, totally decoupled stuff ("(p2p vpn), L4 (mTLS), and L7 (OIDC)").
"Tightly coupled for me, but not for thee" - why would someone who has adopted a decoupled application infrastructure decide that their domain controller should be coupled? I feel like people want one or the other in totality, they are either completely a Windows shop, or they are completely using bits and pieces of everything from everywhere. Everyone in between is ultimately migrating to one end or the other.
I can't speak for how to sell something I've never used. But I know Okta is very popular, and I encounter many IT people in many tech forums basically describe a feature of Okta. That's a huge scope. But that's a company that has tackled the dichotomy of coupled versus decoupled solutions, by simply providing everything. Is there a little bit of a chance that a single person can make something competitive with Okta? Yes!
You'd really only want the current appliance if you don't have the in house staff to assemble/amalgamate an equivalent setup.
My pitch would be that tight coupling enables major security benefits in the implementation:
* rapidly propagate policy updates (eliminate race conditions caused by changes slowly propagating across SaaS vendors.) * simpler modules with fewer features, less attack surface * rich context in logs (even spoofed packets have a cryptographically verified source) * coherent security controls
> something competitive with Okta
I could imagine building the product into "the Okta of on-prem".
OK, now that sounds like a real product with a market, unlike your original post. I don't know if or how you can bootstrap to there (I assume Okta took a bunch of money so that they could blitz out to integrating with everything and didn't need to make sales when they couldn't integrate with everything - maybe building the integrations with a customer's systems as you acquire that customer?) - and I don't know how many people have non-legacy prem systems that they're willing to spend money on. But this is the pitch.
I also hope to evangelize the mentality a bit more. Making the technical approach more feasible for non tech companies could be a boon.
Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.
The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).
----
Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.
There is strong value in security in layers. While VPN access requires remote users to have a hardware key, internal VMs may need a file based pre-shared key/certificate. If an attacker somehow manages to gain VPN access without a hardware key, they’d still either need a hardware key or they’d have to additionally comprise the TLS PKI be able to complete an mTLS connection to an app. Checking the hardware key on the way up the stack keeps an attacker on the VPN from having a privileged position.
Running the same, breached check in multiple places doesn’t make anything more secure, it simply runs a vulnerable check more.
——
Layers do add to security, but the argument here is that you’re adding more doors to a bank vault while completely ignoring they all open with the same key.
In your analogy of the bank robbers, the robbers might exploit a weakness in an exterior wall, and gain entrance to the lobby. The other locked doors will still prevent them from robbing the vault.
Another way to put it is, that attacker is walking a part of the vault floor, but still doesn’t have keys to the lockboxes.
What I’m focused on is the repeated authentication on multiple layers of the network stack. It just isn’t necessary. Either your authentication mechanisms work at the lowest level, or they’re broken across the entire stack.
Even if it's the hardware authenticator your product currently works with.
Don't market it on current specifics; anyone not using a yubikey (personally or organisationally) will dismiss your product and never look at it again if you tie it to one specific third party vendor.
Secure remote access to internal applications
Security is a lemon market so vendor reputation and functional results are more important for winning clients than the implementation ever was.
2. Linked to the above, this is not a competitor to Active Directory. It’s the antithesis. It’s not for a small office of PCs on desktops. It’s to properly secure IoT devices in different locations - sensors, telemetry that niche businesses sell - they sell the service that the device provides, and want a reliable small footprint security solution. Maybe you are it
Edit: I may have misunderstood the use case however - you mention zero trust but I may be missing how it validates at different layers - would love to know more however ! DM me if need be :-)
However, even if I did get that right, your point (1) is excellent.
Smaller ISVs and/or MSPs could quite possibly sell this as part of a bundle, and if you can make it require -less- support than whatever their clients had been using previously that seems like it should make it of significant interest to them.
(I definitely appreciate the 'supporting SMEs is a time suck' concerns in the original post but 'make it less of a time suck for the people already doing it' plus 'turn yourself into 2nd line support only' seems like it could be a way to turn that concern on its head viability wise)
If you do this, make sure you support multiple hardware keys.
Single Yubikey and no backup is not safe, since the key can be lost or damaged easily.
Single Yubikey and SMS backup or "contact customer service to reset" backup is NOT secure, as it reduces your security to that of SMS or the CS rep.
If the active key is lost/destroyed, a self-serve portal allows them to disable their active key at any time. But activating a backup key would require a (different) administrator's approval.
Also, I tend to leave Yubikeys permanently plugged into devices (1 per device) and register all the devices I have (4+) with every service. If any device is lost I would just login with another device disable that key. I also don't usually travel with keys unless I'm travelling with a portable device. When I move between two fixed desktops both in secured locations, the two desktops just have permanently-installed keys, I do not carry a key between them as walking around with a key is a liability.
Almost all of our software is in-house as we're very adept and efficient coders and it keeps the dependencies to a minimum, especially with regards to the licensing. We only have a single non-royalty free dependency and it's a total nightmare, the component is probably responsible for 30% of revenue but 95% of headaches.
So I'm trying to think of a hypothetical where we would buy such a product. Basically if I could have the same flexibility of making such software ourselves I would pay up to what we could expect it would cost to make it. If we were to need it it would be for a ~$1-3M USD project which we could carve off ~$100K for something like this due to the expected dev time savings which could be redirected to other areas while we scale up for the project. But for the second time round pony up bigger chunk say ~$200K to cover the cost of building it ourselves.
We were looking on standardizing on YubiKey, probably for the same reasons you went with them. Honestly I don't think my company should be your target market, we make software and are very good at it so it's a bit hard to sell us software, but if you decide to give out your contact details I'll make a note of it and keep an eye on what you choose to do.
Its not quite where you are now but smaller ISP's tend to have a list of bad options when it comes to user authentication. Do you want to support a large microsoft stack for AD and Radius? Do you want to manage one of the several terrible freely available radius implementations? Do you want to just let your billing system do it and hope that their proprietary code always works? Do you do something different thats completely vendor locked? The list goes on.
Meanwhile, small ISPs are a ridiculously soft target for cybercriminals. Most ISP's think they are invisible, and are exempt from hacking while the inverse is true and the inevitable outcome of that mentality results in heaps of customer data getting exposed.
It would take more market research than "Hey Hackernews" but an all in one appliance that secured userdata, applied stringent security to internal staff, authenticated wfh / field staff vpn logins via yubikey and let the ISP advertise optional secure links over their L2 connections would probably go down really well with small to medium ISP's that have only a few hundred customers, but get 80%+ of their revenue from high value business circuits.
The modern technology stack already allows us to treat the ISP as untrustworthy. For example when I am logging into my bank's website, I don't have to worry if my ISP is snooping on that traffic.
Similarly, I don't understand when people say, don't use wifi at coffee shops. If you are depending on wifi security to provide any protection for your data, you may be doing data security wrong.
1. In terms of the customer facing L3 product: I deleted a whole chunk of this, but the goal isnt so much to deploy this for say your average retail ISP but ISP/MSP hybrids that are offering services to SMEs like L3VPNs, VPLS that sort of thing. Theres been a thrust towards perfecting the fully automated ISP as a service offering where the MSP integrates with the ISP to automate provisioning down to the last mile, have some middle guy designate the correct service definition etc. The problem is that all of these services in practical terms start off swinging terms like SDN around and end up with a half built interface and helpdesk defined networking. Its not even that hard. But its an offering that would take someone who right now pays for say 5 Layer 2 tails in a managed network and convert them over to something like 5 cheaper tails with encrypted by default networking.
Trust me when I say that a lot of people buying products like these trust their ISP implicitly and a service offering that was little to no touch for them to advertise new security features would be well regarded.
2. Even if you have good practices, your ISP is still a risk in terms of PID. This is something that a lot of ISPs want to change about themselves but dont have the time, patience or well lest face it technical capability to resolve. I could fill this forums database with the shit I have seen.
Just a couple of scenarios I have seen that I can easily file the serial numbers off of.
1. Small ISP sold a managed router product. Upon inquiring how they access these managed routers I was given a list of IP addresses and told to use PPTP. The PPTP tunnels were unauthenticated or at best simple creds, running on an alternate port. Saved likely because the vendor used a slightly weird pptp implementation and you may have needed to use their client for some software versions to initiate the tunnel. Customer was also a business with 5 offices and ~ 50 staff.
2. Small ISP exposed its vsphere management to the internet and got completely hosed by cryptolocker.
3. Small ISP stored all its customer details in an excel document in their public web directory.
4. Small ISP would routinely get hosed because they wanted all their infrastructure to be publicly routable, never applied updates and made sure their passwords were simple enough to be memorised by their most venerable field techs.
5. Small ISP provided a "Managed Network" to a serviced office firm. All businesses in the serviced office were layer 2 adjacent.
6. Medium size ISP would pass one clients traffic through up to 3 other customers managed routers before building egress.
7. Medium size ISP had field techs accessing their core network via a shared VPN credential that was not changed during staff turnover.
8. An ISP services platform that is well regarded in a small corner of wisp land uses a single vendors API to do everything. No Radius. No encryption. All tasks are completed by in the clear api calls. There is no vendor supported API based authentication method. So it simply polls every box in the network every minute and updates static ip addresses as needed. The developers have never heard of SNMP, so they just use the vendors built in bandwidth test against every link in your network every few minutes. Dont raise a support ticket, they dont want to know about standards and protocols because they are doing it their way which is the correct way.
The issue is that, depending on where you live in the world, telco can have razor thin margins and the worst salesmen imaginable. They often cant or wont hire a security specialist until its way too late. ISP owners will often just, ask another ISP owner complex technical questions and do whatever the other guy told me. I found a guy selling high value PTP links and he was using a network design that was common for trailer parks, and I asked him how he came up with that, he said he designed his network based around a very convincing facebook post.
You cant fix intentional ignorance. But while its legal for the intentionally ignorant to own and operate telecommunications infrastructure I humbly suggest "The Box" would be a very valuable product.
"The Box" gives you both staff and customer directory services, centralised and encrypted, with access methods requiring a baseline level of security. "The Box" integrates with an idiots favourite network platform for authentication "The Box" gives you super easy to delegate and revokable individually credentialed VPN access for field techs and contractors. "The Box" can handle radius auth or ldap for authentication with most networking hardware
I would actually spend time suggesting this to anyone who has made me facepalm more than 3 times already.
What pain point are you trying to solve?
Your company must: * be quite large, including dedicated security teams * have a rock solid lengthy reputation (or you would need to be a big name in cybersecurity as its founder) * demonstrable security hygiene & certifications (secure development practices, pentesting, SOC2, etc.) * offer products with flexibility to suit my needs * solve a real problem I have, not a theoretical one
It's going to be an uphill challenge to build a company in the security market, unless you're a really big name in cyber. It's a worthwhile challenge, but expect it will take either big investment or a long time starting out before you see the rewards, especially with such a niche product that doesn't really fit into the large enterprise space, and given most small shops won't want the complexity or have the budget for it.
I could bypass this by partnering with a strong reputation. Alternatively, I could de-emphasize "security" in my early marketing as I build my brand: "Easy app deployments!" "Set-and-forget wifi certificates!"
If not, then it's going to constrain businesses who want to open remote offices abroad. For example, having this appliance in a UK office while the US satellite office struggles to use it at latency, isn't a good experience.
Also you haven't mentioned backups. When the appliance eventually fails - which it will - how will a customer restore their data onto a replacement? And if they want to port their data out, how can they easily do this?
Once I can sync two appliances on one site (for rapid failover) the inter-continental syncing should be easy.
Backups are straightforward. A cron job runs a script that dumps all data and builds a debian package with some control files that perform the restoration. The goal was to be able to deploy a new controller with terraform and restore it to a known state. I'm not sure if this is a great production strategy for other companies (do they already have a secure way to sign/encrypt/distribute packages of their clear text configuration data?), it just made my own ops very easy.
Also, for porting out of the product, a seasoned windows admin could probably transfer the LDAP data into Active Directory in an afternoon -- faster, if I took time to document/test the process.
[1] https://learn.microsoft.com/en-us/windows-server/identity/ad... [2] https://learn.microsoft.com/en-us/entra/identity-platform/ms...
I'd seriously started to look into 802.1X but in the "remote work" use case, L2 protection doesn't buy you much because outside your building, an attacker can get L2 access at Starbucks. It seemed like a good feature to leave out of the MVP -- but now I'm wondering if it wouldn't be worth prioritizing.
I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?
> What is an identity provider (IdP)? > > An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO) providers to authenticate users.
Read a full explanation at: https://www.cloudflare.com/learning/access-management/what-i...
- security product, startup, and platform companies
- political campaign offices
- certain law firms
- private military contractors
Most orgs depend on compliance to defray their net risk instead of going this hard to mitigate it. there are cases I'll leave for others, but what the above have in common is they are mission driven and operate outside the compliance narrative.
Go sell it, talk to potential buyers, see what works and what doesn’t, get feedback and adapt depending of that.
There is no point overthinking it especially if you already have a MVP. You will be wrong anyway.
How would you find some people who might be interested? This is the crux of marketing!
* find communities where such folks might hang out. This includes looking at places where self hosting is big (reddit, here, slacks, discords). Read stuff. If there's commercial channel, post there but respect the community.
* find in-person folks to talk to. local linux group meetups, local security meetups, etc.
* look up anyone on linkedin or in your work network and ask for 15 minutes of their time to get ideas on who might be interested in talking to you about this product. Stick to the 15 minutes, though.
* do some google searches that your potential customers might perform. From your description, I'm not sure I'd use the term "domain controller". Seems more like an app gateway or smart proxy instead. See who else is out there and who their customers are.
* searching might also turn up some communities for you to join.
* build a landing page explaining your product (as it will be). Add a mailing list. See if you can get anyone to sign up.
* You could buy some ads to drive folks to the landing page too. Use the same keywords you wanted to use. Set a limit as Google is happy to take your money.
* if you have more time than money, write up a few articles about building this, publish and share them. This sounds like a great topic for HN. Make sure you link to the landing page.
It's not easy, and this is why there are entire marketing and sales departments.
This post is a good overview too: https://www.kalzumeus.com/2013/04/24/marketing-for-people-wh...
Here's some classic patio11 wordplay.
> The other way I did, was I went home to Chicago, which is where my family is from, and took out $400 from an ATM, and walked around downtown Chicago and looked for salons and other massage therapists, that sort of thing.
> I walked in and said, “Hey, do you take walk‑ins?” “Yeah.” “Are you free right now?” “Yeah.” “Are you the business owner?” “Yeah.” “OK, I’ve got a weird proposition for you,” and no, not that kind of weird.
> “What’s the rate on a 30‑minute shoulder massage?” She would tell me. It’s almost always a she. I would say, “OK, I’m going to pay you the rate for a 30‑minute shoulder massage, but what I’m really interested in, I’m a small businessman, I live in Japan, I’m interested in the business of massage therapy. How about we just skip to that post‑massage cup of tea that you’re going to offer me,” I have learned this over the years. “Skip to the cup of tea, I’m going to pick your brains about how you run your business, and then I’ll go, no massage needed, and you get your money?” Almost everybody took me up on that, and nobody called the police. Yay.
* Put a note in your calendar to follow up this thread in 6 months and let everyone know your progress (or your decision not to progress, either is fine :) )
* If you are moving forward, start a startup accountability email list. Super easy to do, free, but will act as a forcing function for your activities. Wrote more on that here: https://www.mooreds.com/wordpress/archives/3324
Finding the right market is hard work and consists entirely of rejection until you find it and entirely of rejection if you don't.
> * Clients who have meaningful IT budgets...
> * Clients who are too small...
Selling is hard work and mostly or entirely rejection. Finding reasons not to sell is much easier and avoids the hard work and the psychological tolls of rejection.
> How would you sell what I've built?
One customer at a time. That's how selling is.
On a brighter note. Hardware is a useful abstraction. Customers with big budgets will pay handsomely for annual service contracts and you can fly out in business class, stay in a nice hotel and markup the cost 25% in the materials section of your time-and materials invoice.
Good luck.