Book a free architecture review with the creator of the most-used SEC Python library. 30 minutes, your actual pipeline, specific recommendations. No pitch deck.
You picked your stack. You wrote the parsers. You shipped the pipeline. And then:
Revenues, RevenueFromContractWithCustomerExcludingAssessedTax, SalesRevenueNet, RevenueFromContractWithCustomerIncludingAssessedTax — and that's just Apple. Your mapping table has 800+ entries and it's still wrong 5% of the time.
SGML headers are inconsistent. Filers submit wrong item codes. Amendments don't follow the same structure as originals. Your filing-to-alert latency is measured in minutes when it should be seconds.
Derivative vs. non-derivative transactions, free-text "nature of ownership" fields, footnotes that contain data the structured XML misses. You're at 70% clean parse rate and the other 30% sits in a queue nobody checks.
You're maintaining two parsers. CUSIP mapping still fails on foreign securities. Your holdings data is months stale because the pipeline silently drops filings it can't parse.
DO NOT REVIVE comment in the README.Someone spent six months on it. They left. The code sits there as a warning to future engineers.
If any of this sounds familiar, you're not alone. SEC data is uniquely awful. EDGAR wasn't built for programmatic access. XBRL has 18,000 US-GAAP concepts with extension mechanisms that make every company a special case. The HTML is inconsistent. The rate limits are aggressive. The documentation is sparse.
This is not a solved problem. But it is a problem we've spent four years solving.
This is a technical review, not a discovery call. You talk to Dwight Gunning — the person who built edgartools — not a sales rep, not an account executive.
You describe your current SEC data architecture. What filing types you process. Where data breaks. What your team spends time maintaining instead of building features.
We ask specific questions: What's your 8-K latency? How do you handle XBRL extensions? What's your Form 4 clean parse rate? Where does your 13F CUSIP mapping come from? This isn't small talk. We're building a mental model of your system.
We pull up your actual filing types in our production platform. Not a canned demo — your companies, your forms, your edge cases.
We show you where the data breaks and why. If you're parsing 10-K HTML for revenue, we show what XBRL gives you instead — and the specific taxonomy concepts that apply to your companies. If your 8-K pipeline is slow, we show the structural patterns that allow sub-minute processing. You see the delta between what you have and what's possible.
We don't end with "let's schedule a follow-up." We end with specifics:
Within 48 hours of the call, you receive a written 1-page architecture brief:
How your SEC data pipeline works today, including specific filing types, data flows, and failure points we identified.
Where your pipeline breaks, loses accuracy, or wastes engineering time, with concrete examples from the call.
2 – 3 specific changes ranked by impact, with enough technical detail for your team to evaluate or act on immediately.
Honest guidance on which problems you should solve in-house, which need specialized tooling, and which need domain expertise.
This is not a proposal for our services. It's a technical document your engineering team can use Monday morning.
DO NOT REVIVE project somewhere in your codebase involving XBRLedgartools is the most-used open-source Python library for SEC EDGAR data. The architecture review is conducted by Dwight Gunning — the person who built that library and runs the production data platform behind edgar.tools. Not a junior analyst. Not a partner who "oversees" the engagement. The person who wrote the XBRL parser that handles 18,000 US-GAAP concepts.
Not conceptually — literally. We know that Apple changed its revenue presentation in 2018. We know that Form 4 footnotes contain grant prices the XML fields omit. We know that 13F CUSIPs fail on foreign securities and that EDGAR rate-limits you at 10 requests per second.
Everything we've built is open source. You don't have to take our word for our technical depth — you can read the parser, review the taxonomy mappings, check the edge case handling. github.com/dgunning/edgartools
This isn't academic knowledge. We process 19 filing types across the entire SEC EDGAR corpus. Our platform serves AI agents through MCP tools and developers through REST APIs. The architecture recommendations we give you come from operating infrastructure, not reading documentation.
We know what you're thinking. "Free consulting" usually means a 30-minute sales pitch dressed up as advice. So let's be direct:
If you want to see edgar.tools, the app is at app.edgar.tools and the API docs are public. You don't need to book a call for that.
The written recommendations you receive are specific to your pipeline and useful on their own. We've designed them to be actionable whether you hire us, use our platform, or do everything yourself.
You talk to Dwight Gunning — the engineer who built edgartools. The conversation is technical. If your pipeline is fine and you don't need help, we'll tell you.
Why do we offer this free? Because every architecture review teaches us something about how teams use SEC data in production. That knowledge makes our library, platform, and consulting practice better.
And honestly — when someone sees their actual filing data parsed correctly for the first time after months of fighting EDGAR, they tend to remember who showed them. We don't need to hard-sell. The problems sell themselves.
Tell us which filing types your pipeline handles and where it breaks. We'll do the rest.
Typically available within 3 – 5 business days. NDA signed before any technical discussion if required.
Prefer email? data@edgar.tools
Free 30-minute architecture review.
Book your review