I work for an enterprise-y and this is good advice. Feature-wise a decent audit log and single sign-on are table stakes. If you don't have those we keep looking, but those shouldn't impact your SME customer focus at all and are things that can be upcharged for (particularly the latter). Core value features available via API is also super important because we absolutely aren't going to be logging into your UI. Again something that can trigger differentiated pricing.
SOC2 is one of those non-functional requirements that can open up markets for you but you're going to pay for in time and energy. If enterprise-y is on your horizon I suggest at least understanding it so you don't make decisions that are counterproductive. But wait until you start to hear the music before you get up to dance with that one...it can be a pain.
Yeah, I've seen this approach work a lot. I've found https://www.enterpriseready.io is a good resource to learn more about the features that enterprises care about.
I'm also working on a solution to make part of this easier, specifically audit logs (https://apptrail.com).
Sort of O/T but why the free tier for your service?
I would think everyone with a legitimate need for an audit trail is a paying customer, in fact would prefer to pay so there is a contract around the audit trail, and “free tier” would just be a drain on your support resources.
We offer a free trial to encourage developers to easily try out and integrate the product.
Our free tier can cover low TPS usecases. We offer a free tier because we believe audit logs are too hard to build & consume and would love to see even smaller companies adding audit logs to their products.
I generally agree with the dimmish view of offering free stuff espoused on HN. However one upside is that grunts at largco can tinker on the side without contracts and all that drag. Diehard freeloaders will just keep signing up if you timebox it but it might filter out the casuals.
AWS CloudTrail is far from perfect but it has been battle tested as much as any SaaS audit log out there.
Who: userIdentity.arn
What: requestParameters.*, responseElements.*
When: eventTime
Where: sourceIPAddress, sourceVpce, userAgent
Why: userIdentity.issuer/rolesession
How: eventName, eventSource
Baller move is to include internal ops actions in your log.
Main thing is to think of it as a product rather than an a feature. People don't want 10 different audit logs...everything should flow through it. With CloudTrail this extensibility comes through the requestParameters/responseElements sections. Most of the schema is fixed but in these sections its service-specific.
In terms of integration, push audit via webhook or various cloud event/message brokers is ideal, but at bare minimum the customer needs to be able to ingest that data wholesale to integrate with their security stack.
I would agree, CloudTrail is a pretty good example. The who what where when why is a good starting point. We're building audit logs as a service and our event format looks similar: https://apptrail.com/docs/applications/guide/event-format
SOC2 is one of those non-functional requirements that can open up markets for you but you're going to pay for in time and energy. If enterprise-y is on your horizon I suggest at least understanding it so you don't make decisions that are counterproductive. But wait until you start to hear the music before you get up to dance with that one...it can be a pain.