Building a Social Media Dashboard Without Being a Developer

I want to start by saying I’m not a developer, or even particularly tech-savvy (yes, I know I work at a tech company). I’ve also never tinkered with AI or built anything myself. For most of my career, I used the tools I needed for work, and when they didn’t do exactly what I wanted, I found workarounds within the tool itself.

But then I started working at Subvisual, surrounded by developers and people far more technical than me, and I noticed something amazing: people just built things. If a tool didn’t work exactly as they needed, they iterated on it. If they needed something that didn’t exist, they built it from scratch. That mindset inspired me to build something of my own to solve a problem I faced every month.

When most people think of social media, they think of the glamorous part: content creation. And that’s a big part of it, of course, or at least the visible one. But a lot of important work happens behind the scenes: reporting.

You can’t just create content for its own sake (or, rather, you can, but it might not perform well). You need to understand your community: whether they’re engaging with your content, whether they prefer single images or carousels, whether they’d rather see a short clip at 9 AM or 9 PM. That means doing the less glamorous work: taking time to look at the data and make sense of it before creating new content.

Every month, I put together our social media report. Before, that meant opening several dashboards: six organic channels and three ad platforms, each with its own layout, logic, and definition of engagement. I then had to compile all that data into a single report, mostly text. It worked, in the sense that the reports got done. But I spent more time collecting data than analyzing it. Tools can help, of course, but they either cost money or don’t give you exactly what you need because they’re built for everyone.

On top of that, you can only report on September’s performance after the month is over. By the time I had the report at the beginning of October and understood what worked (and what didn’t), I’d already planned much of October’s content. Any improvements would only apply later in the month, creating a cycle: you’re always acting on insights that are weeks old. It wasn’t a dealbreaker, but it definitely felt like something that could be different.

So I thought: if my colleagues can build an Ethereum toolkit to replace traditional wallets (with more features), an internal app to centralize and manage the company’s finances, or an internal tool for tracking time and billing, then I could, too.

After sketching out the product, I went to Claude to help me plan and structure it before moving into code. We started with the features I knew (or thought) I wanted: upload reports or enter data manually; filter by date, channel, and metric; get an overview plus a view for each platform; store reports over time; and share them with colleagues.

Then we moved on to design. I wanted it to be visually striking: everything in widgets, with the most relevant data easy to spot. I shared references of dashboards I liked (and why), explained what worked and what didn’t for me, and sent Subvisual brand assets so the design system was set before any code. Once I approved the first overview screen, we went platform by platform to define which metrics to show and how.

As a non-developer, I focused mainly on design and features. How to actually build it didn’t even cross my mind. Luckily, Claude helped with that part too, and SubSocial ended up as plain HTML, CSS, and JavaScript with Chart.js.

Everything was starting to come together. But one problem remained: I was doing everything in the chat, and the product wasn’t turning out exactly as I wanted. I didn’t understand all the hype around Claude. I started losing patience and bluntly asking what it didn’t understand, borderline insulting it (which I try not to do, because you never know when the machines will turn on humans, and I want to be on the nice list). Then I mentioned it on a call with Laura, our COO, and she walked me through a better way to work: one chat for planning, and another for building.

The key was where the building happened. The code chat wasn’t just another chat: it was Claude Code, which works directly with the files on my computer instead of rebuilding everything inside a conversation.

Every session followed the same routine. The planning chat wrote a brief with everything Claude Code needed to know: what SubSocial was, the design system, which files already existed, and what to build next. Claude Code built it, then wrote a summary of what had changed. I brought that summary back to the planning chat, which tracked the whole project and wrote the next brief. It’s not so different from briefing a designer or a freelancer. At least I already knew how to do that part.

With the new routine in place, it was time to get it online.

My computer didn’t even have Node installed. The code chat installed it, set up Netlify, and put SubSocial online. It was live, but full of mock data. Next came Supabase, so the data was actually stored; then I added a login, and the fake numbers disappeared. Then came the ad platforms, with a sidebar split into organic and paid.

Netlify worked, but every update meant asking the code chat to run a deploy command. So I suggested moving it to GitHub, which seemed like the easier long-term option. Claude recommended pairing GitHub with Vercel, so the site would update on its own every time the code changed. I asked why GitHub alone wouldn’t do. It would, technically, but with a long, clunky address. And I wanted a pretty URL. Decision made. From then on, every change I pushed went live on its own.

Not everything went that smoothly, though. The loop between the two chats worked, but it wasn’t flawless. Once, instead of building the feature I’d asked for, the code chat decided to set up a local server, and I had to send it back with a new brief. Another time, it wrote the functions for managing users but never actually deployed them, because the commands hadn’t run. And some things it simply couldn’t do for me, like running a piece of SQL in Supabase so the paid platforms could save data. That one was on me.

By then, SubSocial looked the way I’d imagined. It covered nine platforms, both organic and paid, stored reports in Supabase, and had a login and a live address. But it was still a shell. I had to upload every number by hand, report by report, platform by platform. I’d built a place to see all our data. I just hadn’t found a way to get the data there automatically.

Then came our 2026 summer retreat, with a full day dedicated to building and improving things with AI. Everyone who wasn’t a developer was paired with someone who was, and I was paired with José Francisco, a developer here at Subvisual.

What started that day turned into something bigger. José didn’t just add features to my prototype. He rebuilt it as a real app, keeping the same design, screens, and idea, but making it much easier to maintain and grow. He put it this way: my prototype was the architect’s model that proved the house worked. He then built the house, using my floor plan and finishes.

The original turned out to be 19 separate pages, each with its own copy of the login and the sidebar, so one change meant editing 19 files. Now there’s one shared layout and one template for all nine platforms. SubSocial also moved to Subvisual’s servers, alongside our other internal tools, and now you sign in with your Subvisual Google account. No passwords.

The biggest change was the data. Eight of the nine platforms now pull their numbers directly from the source, with no exports or uploads. We couldn’t connect to Dribbble, so it’s still upload-only.

Live data also revealed something we hadn’t expected: some of my numbers were wrong. Followers were being added up day after day, which made them about 30 times too high. Engagement rate was an average of averages. Ad clicks were being counted as social clicks. Building your own tool also means checking that the numbers mean what you think they mean.

And it wasn’t just me. The first deploy to our servers took four rounds of fixes, and at one point the server kept rebuilding an old version, so three fixes never actually went live. Things break for developers too.

I walked into the retreat with a dashboard I had to feed. Now I have one that feeds itself.

SubSocial is live and functioning. I can now see all the data in a visually appealing, easy-to-access way. I can filter by date, platform, and metric. I don’t need to go to each platform separately to see the data. I don’t need to wait for the end of the month to build a text report and act on insights that are weeks old. When the month does end, SubSocial feeds the data straight to Claude, which writes the report.

So what’s missing? I don’t believe a project is ever truly done. There’s always more to iterate on, add, or remove if it doesn’t make sense. SubSocial already has a Top Movers section planned, with trend comparisons and the best-performing posts, but we haven’t worked on it yet. That’s the next step: seeing what’s growing, what’s slipping, and which posts are behind it. It’s also how I get closer to answering the questions I started with: single images or carousels, 9 AM or 9 PM. After that, I’d like to bring in Subvisual’s product accounts, like ethui, so that other teams can get the same view of their own channels.

Looking back, SubSocial didn’t start with code. It started with the reporting problem and a clear picture of what I wanted to see. I learned everything else along the way.

If you’re thinking about building your own internal tool, here’s what I’d tell you:

• Start with the problem, not the tool. I knew exactly what was slowing down my reporting, and that made every decision easier, from features to design.
• Separate planning from building. That’s when things started working. The planning chat kept the big picture, the code chat did the work, and I stayed in the middle making the calls.
• Expect things to break. They will, even for developers, and fixing them is how you learn how the pieces fit together.
• Know when to ask for help. I got SubSocial far along on my own, but José and a few more calls for help got it where it needed to be.

I’m still not a developer. But I no longer think that’s a reason not to build.