Finding the Right Idea: How SiteSidekick Started

Building SiteSidekick: My Meta AI Hackathon Journey — Part 2

When I started planning my hackathon project, I knew I didn’t want to build something just because it involved artificial intelligence.

I wanted to create something useful.

Something based on a problem I understood.

And ideally, something I could see people actually using.

It didn’t take long for me to start thinking about website troubleshooting.

The Problem I See in My Everyday Work

Working in web design and development means I spend a lot of time helping people with website problems.

Sometimes the problem is obvious.

Other times, a client simply knows that something doesn’t look right or isn’t working the way it used to.

They might say:

“My website looks weird on my phone.”

“I changed something and now the page is messed up.”

“I can’t get into my website.”

“Something is broken, but I don’t know what.”

Those are perfectly reasonable descriptions from someone who doesn’t work with websites every day.

The problem is that there usually isn’t enough information to determine what happened.

Before anyone can fix the issue, somebody has to ask questions, gather details, and narrow down the possibilities.

That initial process takes time.

Thinking About Small Business Owners

I started thinking about what happens when a small business owner doesn’t have an in-house web developer or a dedicated marketing department.

They may not know whether a problem is serious, whether it’s something they can check themselves, or whether they should contact their hosting company or developer.

They may also worry about making things worse.

I wanted to create a tool that could help with those first few steps.

Not a complicated technical diagnostic system.

Not something that would tell users to edit code or change website settings.

Just a practical assistant that could help them understand the situation and decide what to do next.

The Idea Became SiteSidekick

That’s where SiteSidekick began.

The concept was a noncoding website troubleshooting assistant for small business owners.

A user could describe an issue in their own words, answer a few simple questions, and receive guidance based on what they reported.

If the problem couldn’t be resolved through basic checks, the application could prepare a useful summary for a developer.

I liked the idea because it addressed two problems at once.

It helped the business owner feel less overwhelmed, and it helped the developer receive better information.

Instead of starting with “my website is broken,” the developer could receive a description of the problem, what had already been checked, and what was still happening.

Defining What SiteSidekick Should Not Do

This was just as important as deciding what it should do.

I didn’t want SiteSidekick to pretend it could inspect a website when it hadn’t.

I didn’t want it telling business owners to make risky changes to a live website.

I didn’t want it inventing a technical diagnosis.

And I didn’t want users to feel like they needed programming knowledge to use it.

The application needed to distinguish between confirmed information and possible causes.

If someone reported a broken mobile layout, SiteSidekick could suggest checking another phone or browser.

It could explain that image sizing or responsive settings might be involved.

But it shouldn’t claim to know the cause without evidence.

That became one of the guiding principles of the project.

Thinking Beyond the First User

Although I designed the initial version for small business owners, I could also see another use for it.

Small marketing departments and agencies often have more work than available staff.

Sometimes they don’t need another senior developer for every incoming support question. They need help collecting information, organizing requests, and handling the early stages of troubleshooting.

SiteSidekick could eventually support that process.

It wouldn’t replace the judgment of an experienced professional, but it could reduce repetitive intake work and help smaller teams stay organized.

I also began thinking about a business model with a one-time trial option and a monthly subscription.

Those ideas became part of the longer-term plan, rather than features I needed to fully launch during the hackathon.

Choosing a Realistic Scope

One of the biggest challenges was keeping the project manageable.

There were plenty of features I could imagine adding.

But the hackathon had a limited timeframe, and I was building independently.

I needed to focus on a working experience.

The initial priorities became:

That was enough to create a useful application without trying to build an entire customer support platform in ten days.

What I Learned

Having an idea is the easy part.

Defining what belongs in the first version is harder.

I learned that a clear audience, a specific problem, and realistic boundaries are more valuable than a long list of features.

SiteSidekick became a stronger concept when I stopped thinking about everything it could eventually do and focused on what it needed to do well.

Next in the series: Turning the idea into an interface that small business owners could actually understand and use.

Share this:

Like this: