Why We Open-Sourced Our Audit Logging Instead of Using Splunk
The quote from Splunk came in at $96,000 per year. For audit logging. Our CTO read the email, looked at me and said "we can build this." And for once, he was right. Sort of. If you've ever priced enterprise logging solutions, you know the drill. Everything is "contact sales." You fill out a form, wait two days for a call, sit through a demo you dont need, and then get a quote that makes your eyes water. Here's what we were quoted in early 2025: Splunk Enterprise Security: ~$96K/year (based on daily ingest volume) IBM QRadar: ~$70K/year Elastic Security (managed): ~$45K/year Sumo Logic: ~$38K/year For context, our total ARR at the time was about $800K. Spending $96K (12% of revenue) on a logging tool was insane. Even the cheapest option at $38K was painful. And these tools are designed for security operations centers at large enterprises. We didn't need SIEM capabilities, threat detection, or security orchestration. We needed audit logging. Record who did what, make it searchable, make it immutable, let customers and auditors access it. Thats a much simpler problem than what Splunk solves. But the market has this weird gap where your options are either "$100K enterprise platforms with 90% features you dont need" or "build it yourself from scratch." So we decided to build our own audit logging system. Not because we're heroes, but because the math was obvious. Two engineers for two months would cost us about $40K in fully loaded salary. Thats less than half the annual cost of Splunk, and we'd own it. Here's what we built: // Our open-source audit logging core // https://github.com/[redacted] (we actually open-sourced this) interface AuditEvent { id: string; version: '1.0'; eventType: string; actor: ActorInfo; target: TargetInfo; changes: ChangeRecord[]; context: EventContext; integrity: IntegrityInfo; timestamp: string; // ISO 8601 } interface ActorInfo { id: string; type: 'user' | 'service' | 'system'; email?: string; ipAddress?: string; userAgent?: string; } interface TargetInfo { type: string; id: string; name?: string; tenantId: string; } interface ChangeRecord { field: string; oldValue: unknown; newValue: unknown; } // The core API is intentionally simple class AuditLogger { constructor(private store: AuditStore) {} async record(event: Omit): Promise { const id = generateULID(); // Time-sortable IDs const integrity = this.computeIntegrity(event); await this.store.append({ ...event, id, version: '1.0', integrity, }); return id; } async query(filter: AuditFilter): Promise { return this.store.query(filter); } async verify(tenantId: string, timeRange: TimeRange): Promise { return this.store.verifyIntegrity(tenantId, timeRange); } } The storage layer was pluggable. We started with PostgreSQL (good enough for our scale), but the interface allowed swapping in DynamoDB, ClickHouse, or whatever. The core was simple. Two weeks for basic event capture, storage, and querying. But then the real work started. Tenant isolation took another 2 weeks. Row-level security, middleware enforcement, query wrappers, and exhaustive testing. I've written about this separately but its non-trivial. Integrity verification took a week. Hash chains, daily verification jobs, alerting on chain breaks. The query API took 2 weeks. Filtering by actor, by target, by event type, by time range, by tenant. Pagination that works efficiently on millions of rows. Full-text search on event metadata. The customer-facing UI took 3 weeks. An activity log that tenant admins can access, with filters and export. This is what enterprise customers actually care about. They want to show their own auditors that they can monitor user activity in your product. Export and SIEM integration took another week. CSV export, JSON streaming, webhook notifications for real-time event forwarding to customer SIEM systems. Total: about 11 weeks. More than the "two months" we estimated. Shocking, i know. After building this, we realized other startups face the exact same problem. The gap between "DIY from scratch" and "$100K enterprise platform" is massive. So we open-sourced the core library. The reasoning was straightforward: Community contributions: Other teams find and fix edge cases we haven't hit yet Trust: Customers can inspect the code that handles their audit data Recruiting signal: Engineers like working on open-source Business model still works: The library is free, but hosting, management UI, and compliance features are paid This is the same model that PostHog, Supabase, and dozens of other developer tools use. Open core, with a managed offering on top. After running this for 18 months, here's the honest cost comparison: Splunk (what we would have paid): Year 1: $96,000 Year 2: $96,000 (likely more with data growth) Total 2 years: ~$192,000 Our open-source approach: Initial build: ~$55,000 (11 weeks, 2 engineers) Infrastructure (PostgreSQL, message queue): ~$200/month = $4,800 for 2 years Ongoing maintenance: ~5 hours/month = ~$15,000 for 2 years Total 2 years: ~$75,000 So we saved about $117K over two years. But that savings came with real tradeoffs. You become the on-call team for audit logging. When the hash chain verification job fails at 2am, thats your problem. Splunk has a 24/7 NOC. You have your phone on vibrate. Schema evolution is your problem. When you need to add fields to your audit events, you need to handle backward compatibility, migration, and reprocessing. An enterprise platform handles this for you. Scale is your problem. At 10 million events per month, PostgreSQL was fine. At 100 million, we needed to add partitioning, archival to S3, and query optimization. This was another 2 weeks of engineering. Compliance certifications are your problem. If a customer asks "is your audit logging system SOC 2 certified," pointing to your GitHub repo isnt a great answer. Enterprise platforms come with their own compliance certifications. Tbh thats exactly why I built AuditKit. Its the middle ground between build-from-scratch and $100K enterprise platforms. Audit-logging-specific functionality at SaaS pricing, not enterprise pricing. The build vs buy decision comes down to: Build if audit logging is a core differentiator for your product, you have engineering bandwidth, and you want full control Buy enterprise if you're a large org with budget, existing SIEM infrastructure, and need vendor support SLAs Buy SaaS-tier if you need audit logging that works, dont want to maintain it, and dont want to spend $100K According to a 2024 analysis by the Cloud Security Alliance, the average cost of implementing and maintaining custom security logging infrastructure exceeds the cost of a commercial solution within 18-24 months for most organizations. Our experience was an exception because we had the specific engineering talent in-house, but its not the norm. Building our own audit logging taught us a lot about the problem space. Things we would have never learned by just installing a vendor tool. We understand immutability, tenant isolation, integrity verification, and retention policies deeply now. But it also consumed engineering time that could have gone toward product features. Those 11 weeks of build plus ongoing maintenance hours add up. If your a startup evaluating this decision, my honest advice: build a simple version first to understand the problem, then decide if you want to maintain it long-term or migrate to a managed solution. The worst decision is to not have audit logging at all because youre stuck analyzing Splunk quotes. The gap between $0 and $96,000 shouldnt be that wide. And increasingly, it isn't. The market is catching up. But for a long time, we were stuck in that gap, and building our way out was the right call. For us. Your mileage may vary.
