Most vendor evaluation advice assumes the vendor is big. It tells you to request the SOC 2 report, check the compliance page, and confirm the enterprise support tier. That advice is fine when it applies. It is useless the moment you are looking at a product built by three people, or one. A small vendor cannot show you an audit report because there is not one, and demanding it just ends the conversation without telling you anything about whether the product is safe to depend on. The honest question is different: when the standard proof is absent, what should you look at instead. I run one of these small companies, so I will tell you exactly what I would want a careful buyer to ask me, including the questions I find uncomfortable.
The frame that helps most is to stop looking for a guarantee and start looking for reversibility. A large vendor's certifications are a promise that failure is unlikely. A small vendor cannot make that promise as loudly, so the thing that protects you is not a promise at all. It is your ability to get out cleanly if the bet goes wrong. Build the evaluation around that and the right questions fall out on their own.
Start with data export, before anything else
The first question is not about security. It is about exit. Ask the vendor, in plain words, how you get all of your data out, in what format, and whether you can do it yourself without asking them. A good answer describes an export you control, ideally through an API or a standard file format, that returns everything you put in rather than a partial screenshot of it. A bad answer is vague, or routes you through a support request, or quietly reveals that some of your data is not really yours to take.
Export matters more for a small vendor than for a large one, because the small vendor is the riskier bet, and export is what makes a risky bet survivable. If you can leave with your data at any moment, a vendor going quiet is an inconvenience rather than a catastrophe. I hold this so strongly that I treat easy export as a product feature, not a concession. Atlas exposes a public API, which means your records are reachable programmatically and you are never waiting on me to release your own information.
Ask what happens on the worst day
The second question is about breach notification. If something goes wrong with your data, how fast will you hear about it, from whom, and with what detail. You are not looking for a promise that nothing will ever happen, because no honest vendor of any size can make that promise. You are listening for a real process and a straight answer. A vendor who has thought about this will describe how they would detect a problem, how they would contain it, and how they would tell you, without hiding behind legal fog.
With a solo or small vendor there is actually an advantage here worth naming. The person telling you about the incident is the person who understands it, not a communications team three layers removed from the code. That does not make the incident less serious, but it does make the disclosure more direct. I wrote about what an honest disclosure looks like in a post on how enterprise trust is earned slowly, and the core of it is that the first report should be honest even when honesty is expensive.
Plan for the vendor disappearing
This is the question buyers are too polite to ask and should ask anyway: what happens if you stop. A small company can be acquired, wound down, or simply run out of the founder's energy. You are entitled to know how much that would hurt. The answer that matters is not a promise of immortality, which nobody can give, but a description of how little you would lose. Portability is the real protection. If your data comes out cleanly and your workflows are not welded to one proprietary format, the vendor disappearing costs you a migration, not your business.
Some larger arrangements use formal mechanisms like source code escrow, where code is held by a third party and released under defined conditions. It is fair to ask whether a vendor offers anything like that. It is also fair to weigh it against the simpler protection of clean export, which for most small teams does more real good than a legal instrument they will never trigger. Ask about both, and value the one you would actually use.
Find out who answers when you have a problem
The fourth question is deceptively ordinary: who answers support, and how. With a large vendor the honest answer is often a tiered queue where the first person you reach cannot change anything. With a small vendor the answer is frequently the person who wrote the code. That is a genuine strength, and it is worth confirming rather than assuming. Ask how you reach them, what a typical response looks like, and what happens for something urgent.
Be clear-eyed about the tradeoff, though. A solo vendor cannot staff a support desk around the clock, and pretending otherwise would be a lie you should not accept. What you are trading is guaranteed coverage for direct access to the one person who understands the whole system. Whether that trade is good depends on how critical the tool is to you and how much you value speaking to someone who can actually fix the thing rather than file a ticket about it.
Weigh transparency more than a logo wall
The last and most revealing question is about honesty itself. Read how the vendor talks about its own limits. A company that lists what it cannot do, in public, without being forced, is telling you something a logo wall never can. Certifications prove that a process was followed on a given day. Transparency predicts how the vendor will behave on every day you are not watching, which is most of them.
This is the standard I try to hold wrxstack to, and I mean it structurally, not as a slogan. The trust page states plainly that there is no SOC 2 report and no other formal certification today. The security page describes what is in place, SSO over SAML and OIDC and an audit log, alongside what is not. This site even runs an automated check that fails the build if any page claims a control the product does not have. I would rather lose a buyer who needs a certification than win one by implying I have it. When you are vetting a small vendor, that willingness to say no about itself is the closest thing to a certification you are going to get, and it is often more predictive.
| Question to ask | What a good answer sounds like | A warning sign |
|---|---|---|
| How do we export our data? | Self-serve, full, via API or standard format | Vague, partial, or gated behind support |
| How will we hear about a breach? | A real process, direct and prompt notice | No process, or evasive language |
| What if you shut down? | Clean portability, little lock-in | Proprietary format, no way out |
| Who answers support? | The people who build the product | Cannot say, or an anonymous queue |
| What can you not do? | A public, specific list of limits | Claims to do everything for everyone |
| Do you hold certifications? | A straight yes or no, no implying | Hints and logos without documents |
Trial it with real work, not a demo
There is one test that outweighs every document, and it is available to you for free with most small vendors: use the product on real work before you commit. A demo is choreographed. A trial with your own data, on a workflow you actually care about, tells you in a week what a sales call never will. Does the thing hold up. Does export really return everything. Does support answer when you hit a snag. A small vendor that offers a genuine free way in is quietly betting that the product survives contact with your reality, and that bet is a stronger signal than any brochure.
Watch how the vendor behaves during that trial as closely as you watch the product. Do they answer honestly when you ask what the tool cannot do. Do they push you toward a plan you do not need. A small vendor is a relationship more than a purchase, because there are fewer people and less process between you and the product. The trial is your chance to see the relationship, not just the software, before either of you is committed to it.
Match the vendor to the stakes
None of this means a small vendor is always the right choice. It means the evaluation should fit the size of the vendor and the size of the risk. For a tool that runs your regulated core, where an outage or a data question could threaten the company, a large certified vendor may be the only responsible pick, and no amount of charm from a solo builder should change that. For a tool that helps a small team do its work, where the real risk is lock-in and wasted time, a transparent small vendor with clean export can be the better bet precisely because leaving is cheap. Decide which situation you are in before you decide which vendor you want. You can read more about avoiding the trap of tools you cannot leave in a related post on choosing one platform over a pile of tools, and about who is behind this one on the about page.
Is it safe to use a vendor without a SOC 2 report?
It depends on the stakes. A SOC 2 report is an independent examination of a company's controls, and for a critical or regulated system you may genuinely need one. For many small-team tools, clean data export, an honest breach process, and real transparency protect you more directly than a report you will never read. Match the requirement to the risk.
What is the single most important question to ask?
How do we get all of our data out, in a usable form, without your help. Easy export is what makes a small vendor a survivable bet. If leaving is cheap, most other risks shrink to manageable size.
How do I evaluate support from a solo vendor?
Ask who actually answers and how you reach them. The honest tradeoff is that you give up guaranteed round-the-clock coverage in exchange for direct access to the person who built the system and can actually fix a problem rather than file a ticket about it.
Does wrxstack claim any certifications?
No. wrxstack holds no SOC 2 report and no other formal certification today, and says so plainly on its trust page. It does offer SSO over SAML and OIDC, an audit log, and a public API for export. The point of this post is that the willingness to state that clearly is itself a signal worth valuing.
When a small vendor is the wrong call
If the tool would sit at the regulated core of your business, if your procurement rules require an audited vendor before anything can be signed, or if an outage would create real legal or financial exposure, a small or solo vendor is not the responsible choice, and the questions in this post cannot substitute for the certifications you actually need. In that case, go with a large certified vendor and do not let a good demo talk you out of it. This guide is for the many cases in between, where transparency and portability matter more than a logo wall.