This is a submission for the Sanity Challenge

I Vibe-Coded an Accessibility Platform Where Sanity Runs the Community

What happens when you combine AI-assisted development, Sanity, accessibility, career guidance, and a community-driven workflow?

We built ABILITY360 to find out.

ABILITY360 is a platform designed around a simple idea:

Accessibility shouldn't only be about removing barriers. It should also be about creating opportunities.

The platform brings together accessibility information, career exploration, AI-powered guidance, community participation, and accessibility reporting in one ecosystem.

But the interesting part of this project isn't only the frontend.

We wanted to see how far we could push Sanity beyond being just a CMS.

Instead of hard-coding all of our resources and community content into the application, we started modeling them as structured content.

Accessibility resources became data.

Career resources became data.

Community submissions became data.

Accessibility problems became data that could move through a moderation process.

That changed how we thought about the application.

Sanity wasn't just storing content.

It became part of the system that powers the community.

What is ABILITY360?

ABILITY360 is a digital platform focused on helping Persons with Disabilities discover opportunities, access useful information, explore career paths, and participate in a community where accessibility problems can be shared.

We wanted to approach accessibility from multiple directions:

Accessibility + Education + Career + Technology + Community

The platform brings these ideas together through several experiences.

Career Exploration

Users can explore different career paths and understand what skills and learning resources they may need.

AI Mentor

An AI-powered mentor helps users explore career questions, learning paths, and possible next steps.

Resources

Accessibility and career-related resources can be managed as structured content rather than being permanently embedded inside the frontend.

Community

Users can share accessibility problems, requirements, experiences, and ideas.

Accessibility Reporting

A user can submit an accessibility problem or requirement that can then enter a moderation process before becoming publicly visible.

Progress

The platform can be extended toward tracking learning, career development, achievements, and personal growth.

The goal is not to build another static information website.

The goal is to build an ecosystem that can evolve with its community.

Why Sanity?

Our first instinct could have been to hard-code the content.

For example:

const resources = [
  {
    title: "Career Guide",
    description: "..."
  }
];

It works.

But it doesn't scale particularly well when the people managing the platform aren't developers.

What happens when an administrator wants to:

• Add a new accessibility resource
• Update an existing resource
• Publish a community story
• Review a submitted accessibility problem
• Change the status of a report
• Add a new career resource

We wanted these things to be content operations, not code changes.

That's where Sanity became interesting.

Instead of treating content as static frontend data, we modeled it as structured information that could be managed independently from the UI.

Our Content Model

At a high level, our ABILITY360 content structure looks something like this:

ABILITY360
|
|-- Accessibility Resources
|
|-- Career Resources
|
|-- Opportunities
|
|-- Community Posts
|
|-- Accessibility Reports
|
`-- User Requirements

The important part is that these aren't just pages.

They're structured documents.

That means the frontend can consume the content dynamically and the content can evolve without rebuilding every piece of the application.

The Community Workflow

This became one of the most interesting parts of the project.

Imagine a user discovers an accessibility problem.

They shouldn't have to understand our database.

They should simply be able to tell us:

"I found an accessibility problem here."

The application turns that interaction into structured data.

The conceptual workflow looks like this:

USER
 |
 v
Submit accessibility problem or requirement
 |
 v
Pending Review
 |
 v
ADMIN REVIEW
 |
 +------------------+
 |                  |
 v                  v
REJECT            APPROVE
 |                  |
 v                  v
Archived          Published
                     |
                     v
                 COMMUNITY

This is important because community-generated information needs a way to be reviewed.

We didn't want every submission to automatically become public content.

Instead, the platform creates a separation between:

Submission -> Review -> Publication

That gives us a foundation for building a more trustworthy community system.

Why Moderation Matters

When building a community platform, one of the biggest questions isn't:

"Can users submit content?"

It's:

"How do we make community content useful and manageable?"

That's why moderation became part of our design.

A future version could extend this workflow with:

• Duplicate detection
• Community verification
• Evidence uploads
• Location information
• Categories
• Priority levels
• Organization responses
• Resolution tracking
• Report history

The important thing is that the content model gives us somewhere to build these capabilities.

AI and ABILITY360

AI is another major part of the platform.

We explored AI as a career companion, rather than simply dropping a chatbot onto the homepage.

For example, a user could ask:

"I know basic Python and I'm interested in technology. What career paths can I explore?"

Instead of leaving the user with a generic answer, our long-term goal is to connect the response with the rest of the platform:

User Goal
   |
   v
AI Mentor
   |
   v
Career Path
   |
   v
Required Skills
   |
   v
Learning Resources
   |
   v
Projects
   |
   v
Opportunities

This is where structured content becomes especially useful.

If career resources, learning materials, and opportunities are stored as structured content, an AI experience can eventually reason over that ecosystem instead of operating in isolation.

AI-Assisted Development

We also used AI heavily during the development process.

This project was built using a vibe-coding workflow.

Our development loop looked roughly like:

IDEA
 |
 v
PROMPT
 |
 v
GENERATE
 |
 v
RUN
 |
 v
TEST
 |
 v
DEBUG
 |
 v
REFINE
 |
 v
REPEAT

Instead of spending the entire hackathon manually writing every component from scratch, we used AI to accelerate:

• UI prototyping
• Component generation
• Debugging
• Refactoring
• Feature exploration
• UX iteration
• Documentation
• Architecture discussions

But there was an important lesson here.

AI-generated code isn't automatically good code.

We still had to understand what the code was doing, where the data was coming from, how the components connected, what happened when something failed, and whether the implementation actually matched the product requirement.

Vibe coding made us faster.

It didn't remove the need to think.

Building With Sanity Instead of Around Sanity

One of the biggest changes in our thinking was moving from:

Frontend
   |
   v
Hard-coded content

to:

Frontend
   |
   v
Structured content
   |
   v
Sanity
   |
   v
Content and community data

This made the application more flexible.

For example, instead of modifying code every time we want to add a new accessibility resource, the content can be managed through the Sanity environment.

That separation between content and presentation was one of the biggest reasons Sanity fit the project.

Sanity Studio

Sanity Studio gives us an interface where structured content can be managed instead of requiring a developer to modify the frontend.

For ABILITY360, this is particularly useful for things such as:

Accessibility Resources

Administrators can manage resources without changing application code.

Career Content

Career-related information can be maintained separately from the UI.

Community Content

Submitted content can be reviewed and managed.

Reports

Accessibility reports can have structured information and status.

This turns the admin side of the application into something more useful than a traditional dashboard full of hard-coded tables.

Going Beyond a Traditional CMS

One thing that stood out to us while exploring Sanity was the possibility of building applications that sit much closer to the content itself.

Instead of thinking:

"Sanity stores our blog posts."

We started thinking:

"Sanity stores the structured information that powers our ecosystem."

That opens the door to future extensions such as custom interfaces, richer workflows, real-time experiences, and integrations with external services.

For example, a future version of ABILITY360 could have a dedicated moderation interface where an administrator sees:

New Accessibility Reports
-------------------------

Report #1042
Location: XYZ
Category: Physical Accessibility
Status: Pending

[View Evidence]

[Approve] [Request Changes] [Reject]

The important part is that the workflow would operate on the same structured content that powers the public application.

What Was Hard?

The hardest part wasn't generating the first version.

AI can make that surprisingly fast.

The difficult part was making the pieces work together.

We had to think about:

Data Structure

What should be a document?

What should be a field?

What information should be reusable?

User Experience

How can someone report an accessibility problem without being overwhelmed by forms?

Moderation

How should submitted information move from pending content to public content?

Scalability

How can we add more resources, opportunities, reports, and community contributions without turning the frontend into a giant collection of hard-coded data?

These questions made us think less like people building a demo and more like people designing a product.

The Hackathon Reality

Vibe coding sounds magical until the generated code meets reality.

Sometimes the first implementation works.

Sometimes it almost works.

Sometimes it creates a beautiful component that has absolutely no idea where its data is supposed to come from.

And sometimes fixing one thing breaks another.

Our workflow became:

Build -> Test -> Break -> Understand -> Fix -> Improve.

That was probably one of the most valuable parts of the experience.

We learned that the real advantage of AI-assisted development isn't that you never write code manually.

It's that you can explore more ideas in the same amount of time.

Why We Chose This Problem

Accessibility is often discussed in terms of infrastructure.

But accessibility also involves:

Information.

Education.

Employment.

Technology.

Community.

A person may have the skills required for a job but struggle to find an accessible workplace.

A student may want to enter technology but not know which career path to follow.

Someone may encounter an accessibility barrier but have no structured way to communicate it.

ABILITY360 tries to connect these experiences.

What's Next?

The hackathon version is only the beginning.

Accessibility Map

A community-powered map showing accessibility information and reported barriers.

Inclusive Job Marketplace

Connect candidates with organizations offering accessible employment opportunities.

Workplace Accessibility Profiles

Organizations could publish structured accessibility information about their workplace.

Community Verification

Allow multiple community members to verify whether a reported accessibility issue still exists.

AI Report Classification

AI could help categorize incoming community submissions and identify potential duplicates before human review.

Evidence-Based Reporting

Allow users to attach images or other evidence to accessibility reports.

Personal Career Roadmaps

Connect AI recommendations with structured career resources and opportunities.

Richer Sanity Workflows

As the platform grows, we want to explore deeper Sanity capabilities for moderation, real-time experiences, and custom interfaces around our content.

What I Learned From the Sanity Challenge

The biggest lesson was that a CMS doesn't have to feel like a separate system sitting behind your application.

When content is modeled correctly, it can become part of the application's architecture.

For us, that meant thinking about:

Content as data.

Community submissions as content.

Moderation as a workflow around content.

AI as a layer that can work with structured information.

And that opened up a much bigger design space than we initially expected.

Hackathon Experience

Building ABILITY360 was a combination of product thinking, rapid development, debugging, and a lot of experimentation.

Our team, Aithians, started with a broad accessibility problem and gradually turned it into a platform concept.

The most memorable part wasn't a particular line of code.

It was watching the project evolve.

At the beginning, we were asking:

"What should we build?"

Later, we were asking:

"How should the data flow?"

And eventually:

"How can this become a platform that people can actually use?"

That's the progression I enjoy most about hackathons.

You start with a problem.

You build something quickly.

You break things.

You learn.

And sometimes you end up with an idea that feels worth continuing after the hackathon ends.

Final Thoughts

ABILITY360 started as a hackathon project.

But the bigger idea is much more ambitious.

We want to explore what happens when accessibility information, career development, AI assistance, and community participation are connected through a platform that can continuously evolve.

Sanity helped us think about the application differently.

Instead of treating content as something we add at the end, we treated structured content as part of the product architecture.

And that's probably the biggest thing I'll take away from this challenge.

Don't just build a frontend around your data.

Design the data, workflows, and experiences together.

ABILITY360 is still evolving.

But that's exactly what makes building it exciting.