Skip to main content

I'm Not a Developer. Here's How I Built it Anyway (API/AI/Reporting Series Part 2)

  • July 31, 2026
  • 2 replies
  • 33 views

DStack
Forum|alt.badge.img+6
  • Participating Frequently

The response to the last post was pretty cool: people reaching out in DMs, phone calls, email, LinkedIn (let's connect!), etc. Keeping it going, but shifting the topic a bit for this post. A lot of you asked less about the reports, more about how this actually gets built. So here's that post.

Fair ask. The replies and DMs from the first post were more like "okay, cool report, but how does the plumbing work, and how are you, a non-developer, actually doing this with AI?" So let's get into it.

Staying organized was the real unlock

Early on I was starting fresh in every conversation, re-explaining the same context each time. Once I figured out you could set up a persistent "project" (give it real context about what we're building, our conventions, our data's quirks), it stopped being a series of one-off chats and started being an actual system that builds on itself. That's the difference between "cool, made a report" and where this ended up.

A few things I said upfront to AI that mattered more than I expected

  • I'm not a developer: explain things, don't assume I know the jargon.
  • Flag security and data concerns before I even think to ask. Protecting client and company data was non-negotiable from day one.
  • Don't just agree with me. If there's a better way, say so. No ego amigo, best idea wins.

That last one's the one I'd tell anyone to steal (for prompting AI or managing people and teams!). The plan gets better constantly when the thing helping you build isn't afraid to tell you your first idea has a hole in it. Early on I'd float something, get pushed back on it, and end up somewhere better than where I started. That's the difference between simply using it as a tool and treating it like an actual collaborator.

Two habits that made the difference between "neat idea" and "usable tool"

Instead of typing instructions straight into a terminal and hoping they land right, I write the task out as a plain text file first, then just point Claude Code at it: "read this and follow it." Small thing, made a real difference in how cleanly work landed. This was a big unlock for me when iterating on versions of a report quickly. Before this, I was manually pulling a version, reviewing it, sending notes, and re-running it. Once I learned to give Claude Code the notes (and the safety guardrails), I would turn it to auto mode and it would repeat this process automatically until it had a version good enough to share for approval.

I keep a file that's basically "here's how we do things around here" (conventions, gotchas we've hit, decisions made) and it updates itself as we go, so I'm not relearning the same lesson twice three months later.

On the API side

I'll keep this conceptual. Happy to go deeper in the comments if people want specifics. At the core it's not that different from what a lot of you do manually already: authenticate/log in, pull the data you need, shape it into something usable, hand it off. The part that actually eats time isn't the connecting: it's learning your own data's quirks. What's reliable, what looks right but isn't. That has a lot to do with how you're already using Aspire. The more consistent your team is with how you use it, especially data entry, the better the output.

Build it yourself, or hand it off?

Since the first post I've heard from both camps: people who want this built for them, and people who want to build it themselves. Both make sense. With how fast tech's changing right now, what matters most is staying genuinely open to adapting, whichever camp you fall into. If you're in the second camp, I'll be straight with you: it's more approachable than it used to be, but it's not a weekend YouTube project either. Everyone's got access to the same tools now. The part that's actually hard to copy is the judgment: what to build, what not to, and how you use it. If you're more in the "want this built for me" camp, I'd check out what the guys at ​@CapsaAnalytics have built. I spoke with Brent briefly last week, and they've got a polished, plug-and-play product.

Curious which camp most of you are in: building it yourself, or looking for something that already exists? And for anyone already trying to build: what's tripped you up so far?

2 replies

CapsaAnalytics
Forum|alt.badge.img+9
  • Participating Frequently
  • July 31, 2026

@DStack thanks for the shoutout! I’ve published some basic code you can use for getting started here as well: https://github.com/brent-lemieux/capsa-connectors

Just point your AI agent in claude code or chatgpt codex at this as an example along with what ​@DStack posted above.

 

This doesn’t handle every nuance of the Aspire API -- there are some tricky bits to keep the data up to date and accurate, but this is a good jumping off point!


baraica
Community Manager
Forum|alt.badge.img+30
  • Community Manager
  • July 31, 2026

Thanks for inspiring the community!