My Developer Accelerator Playbook

Your venture, in your own words

I'm one of two co-founders of Bracket, a four-person team in Bristol building an open-source wallet-connector library for Cardano. It gives dApp developers one API instead of hand-rolling support for Nami, Eternl, Lace, Flint and the rest separately. About 40 dApps now import it in production and we get roughly 8,000 weekly npm downloads. We're funded, not bootstrapped: two Catalyst grants, Fund 10 (40,000 ADA, built the CIP-30 core) and Fund 12 (65,000 ADA, added CIP-95 governance-key support), the second of which has one milestone left to sign off. Beyond that we have two small paid support retainers, about £1,000 a month combined, for priority fixes. There is no product revenue: nobody pays a licence fee for the library itself, so income depends entirely on grants renewing or converting into something people will actually pay for.

What you want from this programme

The commercial problem I most want solved is what Bracket earns money for once Catalyst funding stops. Right now our income is entirely grant cycles plus two support retainers, and neither retainer would survive us going quiet for a month. I want to leave the programme with a decided answer on whether we charge for anything, what that is, and a rough price, rather than another six months of 'we should probably think about monetising'. The second thing I want is to stop being the two-person single point of failure for every integration question. If a wallet update breaks something and both Priya and I are unreachable, nothing gets fixed. I want a documented way for Alex or Jess to answer a class of these questions without waiting on us.

How you will make the time

I can give this six hours a week, Tuesday and Thursday mornings before the daily Discord triage starts, and Priya is doing the same on Wednesdays. Support tickets and the current Fund 12 milestone write-up are what will genuinely get squeezed, which worries me a bit given the milestone deadline. Realistically the thing that derails it is a wallet vendor shipping a breaking change mid-week, because that always jumps the queue.

The decision you are facing, and what kind of problem it is

The decision in play is whether to put a paid 'priority support' tier in front of the library before the Fund 12 money runs out at the end of Q1 2027, rather than waiting for a Fund 14 grant that may not come. The technical part, what a support SLA would actually cost us in hours and whether our issue tracker can be metered at all, is something a contractor familiar with support tooling could analyse and settle in a week. The part that isn't analysable is whether charging any of our 40 dependent dApps changes how the community sees an open-source project it currently trusts as neutral infrastructure. That's a judgement call about what Bracket is for, and I don't think an expert answers it for us.

The same decision, read through VUCA

One fragility in your venture, read through BANI

The pressure is that Priya and I are the only two people who can diagnose a wallet-specific integration bug end to end, and Alex and Jess both defer to us even on issues they could probably solve themselves. That's brittleness: the system looks fine under normal load, all four of us shipping and triaging, but it has no give if either of us is out for a week. The observable evidence is our own GitHub assignment history: of the last 30 non-trivial issues, 26 were closed by one of the two of us, even though Alex closed most of the routine dependency bumps. I used to read that as 'we're just the most experienced', which is true but beside the point, because it means depth has never been tested. What it changes is that documenting wallet-specific quirks properly is not a nice-to-have anymore, it's the only lever that turns brittle into merely fragile.

One technology development worth watching

The development I'm watching is CIP-95's governance-key delegation moving from optional to expected: Intersect's governance tooling updates (their GitHub, last commit 15 September 2026) increasingly assume a wallet exposes a governance key by default, not just a payment key. The evidence is that three of the wallets we support, Eternl, Lace and Typhon, have already shipped governance key exposure in their extension APIs this year, and dRep tooling built against them is starting to appear. The possible effect on Bracket is that our CIP-95 support, which Fund 12 paid for, could become the main reason dApps adopt us over rolling their own connector, if governance UIs become as common as wallet connects are now. The dependency I'd need to understand properly is how consistent the governance-key data actually is across wallets in practice, not just on paper in the CIP. Next review point: after the Fund 12 milestone ships, check dRep tool adoption numbers again in December.

Where your venture sits on Survive, Stabilise, Thrive

My Reality, my Vision, and the Bridge between them

Reality: Bracket is a library with real adoption, about 40 dApps and 8,000 weekly downloads, but zero product revenue and two people who are the only ones who can fix a hard bug. Two Catalyst grants have paid for everything we've built; the second has one milestone left. My Commercial Vision is that in five years Bracket is the default connector for Cardano dApps the way a well-known JS auth library is for web apps, with a paid support and reliability tier funding two more engineers, not grant-dependent. My Cultural Intent is that nobody on the team is a single point of failure for a piece of the codebase, and that we're known for actually fixing wallet bugs fast rather than just merging PRs. The bridge is unglamorous: write down what Priya and I know that isn't written anywhere, and use that same documentation to scope a priced support tier, because it's the same knowledge either way.

My Full Value Audit: four biomes, sixteen areas

My most material finding, and what I will do about it

The material finding is value-model: importance 5, performance 2. It sits in the Essence biome, the layer everything else rests on. The evidence is blunt: every pound of income Bracket has ever received has been a grant tranche or a support invoice I raised myself, there is no mechanism that captures value automatically from the 40 dApps using the library daily. The uncertainty I couldn't resolve on my own is whether those dApps would actually pay for anything, since 'it's free and good' is exactly why they adopted us, and I don't have a clean way to test willingness to pay without looking like we're about to ruin something people rely on. The action: run three direct conversations with dependent dApp teams before the end of October, asking what they'd pay for a reliability SLA specifically, not a general 'would you pay' question, and bring real answers into the funding-routes work in module 600 rather than guessing.

How my venture creates, delivers and captures value

The one asset I will build or buy next

The asset I'll build next quarter is a written wallet-quirks knowledge base, the undocumented edge cases Priya and I currently hold in our heads about how each of the six wallets actually behaves versus what its docs claim. That's Intellectual Capital, and it's intangible: no balance sheet line will ever show it, but it's the actual thing that makes Bracket work when a wallet breaks something. Buying it as a contractor's write-up would be faster, but we'd lose the nuance, so we're building it ourselves, in the gaps between the two of us handling live issues. It matters because it's the same asset either way we go: it lets Alex and Jess close harder tickets without escalating, and it's the raw material for pricing a support tier honestly instead of guessing what we'd be promising.

Your entity, your lens, and your purpose

This playbook is written for Bracket as an organisation, the four of us together, not for me individually or for Bracket Software Ltd as a legal shell. That's the right level because the bottleneck problem I'm trying to solve, everything routing through two founders, is precisely about whether the organisation can function as more than its legal owner. Our purpose: we exist to make connecting a dApp to a Cardano wallet a solved problem, so smaller teams spend their limited time on their actual product instead of six different wallet integrations. If Bracket disappeared tomorrow, roughly 40 teams would have to go back to writing and maintaining that plumbing themselves, badly, in parallel.

Your Commercial Vision, your Cultural Intent, and the decision that tests them

Commercial Vision, ten years out: Bracket is the connector almost every serious Cardano dApp ships with by default, something like 300 projects depending on it, and we earn a genuine living from a reliability and support tier that maybe 30 of the highest-traffic teams pay for, alongside occasional grant funding for genuinely new protocol work rather than for keeping the lights on. Revenue is closer to £250,000 a year across the team, not spectacular, but real and not dependent on a Catalyst round landing on time. Cultural Intent: nobody on the team is irreplaceable for longer than a fortnight, because everything hard is written down, and we're known in the Cardano developer community as the people who actually fix your bug rather than the people who close your issue as stale. The decision that tests both right now is the paid-tier question from module 100: saying yes moves us towards the commercial vision, but only if we do it in a way that doesn't quietly abandon the cultural intent of being the trustworthy free option too.

The value you create, and how it is exchanged

Your business model, and what it rests on outside

Your Finance Model

Foundations: known income is the remaining Fund 12 tranche, roughly £9,000 due on milestone sign-off, plus £1,000 a month combined from two retainers. Known costs are about £7,500 a month, mostly the four of us paying ourselves modestly plus hosting and tooling. What I don't know precisely is our real burn if a wallet-breakage spike forces paid overtime hours, because we've never tracked hours against a bad week specifically. Insight: we budgeted the Fund 12 milestone for six weeks and it's taken nine, entirely because of the two wallet API changes in August, so our planned-versus-actual gap is entirely support-driven, not scope creep. That matters because it means our costs are more volatile than our income, which is the wrong way round for a team with no cash buffer. The obvious next step, before any pricing decision, is to actually cost a bad month properly rather than budgeting from an average one.

Your Full Value Dashboard

The five propositions, one line each

Your value proposition

The problem, in a dApp developer's words: 'every wallet does CIP-30 slightly differently, and I don't want to be the person who maintains six integrations forever.' The mechanism: Bracket sits between the dApp and the wallet, normalising the connection, signing and now governance-key calls into one consistent API, so wallet-specific quirks live in our code, not theirs. The value delivered is time: teams tell us, informally, it saves a few weeks up front and then ongoing maintenance every time a wallet ships an update, since that update is our problem to absorb, not theirs. The target customer is a small Cardano dApp team, typically two to six people, without a spare engineer to own this. The real alternative isn't a competing library, it's doing nothing, which means either hand-rolling the integration themselves or shipping support for only one or two wallets and losing users who use the others. What differentiates us is simply that we've already done the unglamorous wallet-by-wallet debugging work and kept it maintained for two years, which is hard to fake with a fresh fork.

Your customer avatar and the promise you make them

The position you are claiming

One partner relationship, both sides of it

The partner I'll use is our largest retainer client, a DEX aggregator with maybe 15,000 monthly active users, who pays us £600 a month for priority support on their wallet integration. They contribute the £600 plus early warning: because their traffic is high, they're usually the first to notice when a wallet breaks something, often before we see it in our own monitoring. In return they get faster fixes than the free tier and direct access to Priya and me rather than the public queue. What each side has actually promised, though, is looser than it should be: they've never signed anything specifying a response-time SLA, and we've never committed to one in writing, we've just always delivered fast so far. The mechanic I haven't managed is what happens the first time we can't meet that unwritten expectation, because right now the relationship's goodwill has never been tested by a genuine failure on our side, and I don't know if it survives one.

Your revenue engine, function by function

The capability constraint that most limits delivery

The capability constraint is training: nobody but Priya and me has actually practised diagnosing a wallet-specific bug end to end, because we've never deliberately handed one over and let someone else struggle through it with us watching rather than fixing it ourselves. It isn't unclear roles, Alex and Jess both know what they're meant to own; it isn't engagement, both are keen to take on harder work; and it isn't workforce management, we have enough hands for our current ticket volume most weeks. It's specifically that the skill of reading a wallet's actual behaviour against what its docs claim has never been taught, only demonstrated by us, repeatedly, while the person watching learns to wait for the answer rather than find it. The fix has to be deliberate: pick the next hard wallet bug and make Alex own the diagnosis while I only answer questions, not solve it for him.

What your venture owns, controls or depends on

Your relationship assets

The finding you would act on first

Reading the four together, the finding is that our revenue engine's weakest handover, hard bugs never reaching Alex, and our capability constraint, nobody's practised diagnosis except us, are the same problem described twice. Communications constrains capability here: because decisions and hard problems stay in the Priya-and-me channel, Alex never gets the exposure that would turn his growing skill, which the relationship-assets row already shows is real, into something the team can rely on. I can tell because his governance-key work this milestone was solid, unprompted, and largely invisible to us until I looked for it. The owner is me, since I'm the one who currently intercepts issues before they reach him. First step: for the next four hard GitHub issues, assign them to Alex first and only step in if he asks, rather than the reverse.

Your PESTLE scan

The funding need, defined before the source

The work that needs resourcing is finishing the CIP-95 governance milestone under Fund 12 and, separately, the unfunded work of writing down our wallet-quirk knowledge and testing a paid support tier, neither of which any grant currently covers. It needs to establish whether Bracket can earn income that isn't a grant tranche, by the time Fund 12's final payment lands, roughly Q1 2027. Very roughly it requires £8,000 to £10,000 to cover two months of the team's time on documentation and a small pilot with three dApp teams, on top of normal running costs. Fund 12's remaining £9,000 covers the governance milestone itself and nothing beyond it. Our two retainers contribute £1,000 a month, useful but nowhere near enough to bridge a gap if Fund 12 is the last grant we win. Customer revenue currently covers about 12% of monthly costs; the honest number is that grants have covered the other 88% for two years running.

Routes against that need

Who holds influence, and who is affected

One external change, traced across all three areas

The change is Intersect's governance rule update for Catalyst funding rounds in March 2026. What I observed is that the committee structure for reviewing proposals changed and some previously eligible categories, including ongoing maintenance funding, got tightened. What I think it means, and this is inference not fact, is that a Fund 13 or 14 proposal framed as 'keep maintaining what we built' is less likely to land than one framed as new protocol capability, though I haven't confirmed this with anyone at Intersect directly. Traced through: on the external environment, it changes how we'd need to write any future proposal, leading with new governance tooling rather than maintenance. Internally, it costs us actual capacity, because writing a stronger proposal takes real hours away from the support-tier pilot in module 600's funding-need answer. On relationships, it puts more weight on our two retainer clients and the pilot succeeding, since public funding just got less certain, and that's a commitment I haven't yet made explicit to Alex and Jess, who don't know how much this shifts our risk.

One priority, threaded through your playbook

The priority is deciding and piloting a paid reliability tier before Fund 12 ends. Essence: it serves the part of our purpose that says dApp teams shouldn't have to think about wallet quirks, by making that promise explicit and fundable rather than an informal thing we happen to do for free. Market: the user is the same small dApp team from the customer avatar, the difficulty is wallet breakage on update day, and the evidence is that our two existing retainer clients already pay for exactly this, we just haven't offered it more widely or priced it properly. Internal: Priya leads pricing and the pilot conversations, I write down the wallet-quirks knowledge base that the tier is actually selling, and Alex takes on diagnosing at least one hard bug independently as proof the team can deliver this without me and Priya personally. External: this responds directly to Catalyst's tightening rules on maintenance funding noted in module 600, since a paid tier is the alternative to depending on the next grant landing. It also needs watching against community trust, because the wrong pricing move risks the free-and-open positioning that got us here.

Your development priorities, and what waits

Five candidates, drawn from earlier answers, not fresh brainstorming. One: write the wallet-quirks knowledge base (module 200's asset investment), evidence is the brittleness finding in module 100, needs roughly 15 hours a week from Priya and me for a month. Two: pilot a priced support tier with three dApp teams (module 200's material finding and module 600's funding need), needs Priya's time on conversations and my time on pricing logic, maybe 5 hours a week over six weeks. Three: hand Alex the next four hard bugs unassigned to founders (module 500's internal audit finding), needs restraint more than hours, mainly me not intervening. Four: formalise the two retainer contracts with an actual written SLA (module 400's partner proposition gap), a half-day of legal-adjacent writing. Five: automated compatibility testing against wallet extension updates (module 600 PESTLE, technological row), real engineering time, probably two weeks of Alex's time. What waits: any new feature work beyond CIP-95 completion, and any Fund 13 proposal drafting, both explicitly deferred until the pilot above tells us whether a paid tier is worth pursuing at all.

The evidence you will watch

The same plan under three conditions

Your implementation plan for the next 90 days

The situation I am leading through

Not yet answered.

My leadership stance in this situation

Not yet answered.

What my behaviour is teaching my team

Not yet answered.

Preparing the conversation I have been avoiding

Not yet answered.

Where I am on the journey, and what my team needs next

Not yet answered.

The change I am committing to

Not yet answered.