Guided setup walkthroughs for AWS graph and ledger databases

A developer picks Neptune or QLDB because their use case genuinely fits — fraud detection, supply chain provenance, identity graphs — and then spends two weeks just getting a working local development loop and understanding how Gremlin traversals map to their data model. The complaint that 'it was somewhat complicated to use at times' and that it's 'challenging to comprehend and utilize with others' points to something specific: these databases have unfamiliar query paradigms (Gremlin, SPARQL, PartiQL for ledger) that have no close analogy to SQL, and the learning curve isn't just steep, it's discontinuous.

The gap persists because AWS documentation is written by people who already understand the paradigm, not by people who had to learn it from scratch. AWS has no structural reason to fix this: their support tiers are profitable, and teams that struggle either escalate to paid support or abandon the service for something more familiar — both outcomes are fine for AWS. The user who suffers is the engineer; the person who could buy a fix is the engineering manager who keeps seeing their team blocked.

What's missing isn't more documentation — it's opinionated, use-case-specific setup paths. The complaints about 'choosing the most suitable one' across multiple solutions suggest that users are being handed a menu when they need a recommendation. Existing tutorials are either too shallow (hello world) or too deep (full production architecture), with nothing in between for someone who knows their use case but doesn't yet know the database's mental model.

This is a business because onboarding a new database service is a recurring event — teams add new services, new hires join and have to get productive, and the same friction repeats. A manager who pays once to make their team productive faster on Neptune will pay again when they adopt another unfamiliar AWS service. The recurring trigger is team growth and service adoption, not a one-time setup.

What to build

Build a structured, interactive onboarding guide for Amazon Neptune and QLDB that starts by asking the user to describe their data model and use case in plain language, then walks them through schema design decisions, query pattern examples in Gremlin or PartiQL, and a working local environment config — all scoped to their specific use case rather than generic documentation.

Where to start

Start with Neptune fraud detection use cases specifically, because it's the most commonly cited Neptune use case in AWS case studies, has a concrete enough data model (transactions, accounts, relationships) to make the walkthrough opinionated and credible, and the teams working on fraud tooling have budget and urgency.

The hard part

The hardest early challenge is that Neptune and QLDB have small enough user bases that finding the first ten paying customers requires very targeted distribution — likely through AWS Marketplace or community channels like the Neptune Discord — and the addressable market is narrow enough that pricing has to be high per seat to sustain the business.

How it makes money

Per-seat subscription at $49/month per developer, with a team onboarding package at $499 flat for up to 10 seats covering the first 90 days of a new Neptune deployment.