Curiosity-Driven Software

Build What Matters.

Every experiment begins with a simple observation.

Explore Experiments Why Big Sand Labs?

Observe
Experiment
Share

Philosophy

Every experiment begins with curiosity. The good ones earn a future.

Explore ideas by building. Share what proves genuinely useful.

Observe
Pay attention to the everyday problems.
Experiment
Start small. Every experiment teaches something.
Share
When something proves genuinely useful, share it.

Experiments

Built from Curiosity

Ideas become experiments. The best ones become products worth sharing.

EXP-001Experiment
SwingTrader
Finding strong stocks shouldn't mean sorting through endless charts and indicators. Surface high-quality swing-trading setups using trend, momentum, entry quality, and risk.
Open
Why I Built It
I wanted to turn the Minervini-style swing-trading process I use into a repeatable tool that could screen stocks, help evaluate setups, and apply my own risk rules consistently.
What I Was Exploring
Encoding a Minervini-style trading methodology into software
Separating setup quality from entry timing
Translating personal capital and risk preferences into position sizing
Making sophisticated controls understandable through progressive disclosure
Separating personal Risk Profile from current market conditions
Turning a Python and Streamlit workflow into something accessible from a static website
Built With
Python, pandas, yfinance, Streamlit, HTML, CSS, JavaScript, GitHub Actions, GitHub Pages, Wikipedia ticker lists, and Yahoo Finance market data.
What I Learned
Turning a strategy into software forces assumptions and thresholds to become explicit.
GitHub Pages cannot run the Python scanner, so the scan had to be generated as a snapshot and then re-filtered in the browser.
Static hosting changes architecture, not just deployment.
Language matters: “Buy Now” made the tool sound like financial advice, while “Entry Ready” better reflected its purpose as a personal decision tool.
Risk Profile and market conditions sound similar but represent very different concepts.
Progressive disclosure and removing empty UI often improved the experience more than adding additional controls.
EXP-002Experiment
PokeScout
Learning Pokémon shouldn't mean jumping between websites. Explore Pokémon, moves, type matchups, and battles—all without leaving the page.
Open
Why I Built It
My sons like Pokémon, and I wanted a simple way to learn about the different Pokémon, battles, evolutions, and type matchups without constantly jumping between websites.
What I Was Exploring
Working with a nested public REST API without a backend
Translating type-effectiveness math into plain language
Simplifying dense Pokémon information for beginners
Designing detail pages that reveal information progressively
Making branching evolution paths understandable on a phone
Deciding how much information someone actually needs at once
Built With
Vanilla HTML, CSS, and JavaScript, PokeAPI, Node's built-in test runner, and GitHub Pages.
What I Learned
Showing data is easy; making complicated relationships understandable is much harder.
Removing features often improved the product more than adding them.
Mobile evolution trees required their own design rather than simply shrinking the desktop version.
Dual-type math and evolution trees turned out to be some of the hardest parts of what initially looked like a simple lookup tool.
Even a static API-driven site benefits from caching, batching, stale-request protection, and testing.
EXP-003Experiment
PorchLight
The best playgrounds aren't always next door. Discover shared adventures for families who don't live in the same neighborhood.
Open
Why I Built It
My grandchildren live in different places, and I wanted to explore whether an interactive world could give family members another way to play and spend time together even when they aren't in the same neighborhood. It also gave me a reason to learn how characters, environments, animation, and game experiences are created.
What I Was Exploring
Creating storybook environments inspired by real family places
Designing characters and turning them into sprites
Creating sprite sheets, walk cycles, and character movement
Using Recraft to create characters and visual assets
Exploring Rive and other animation approaches to make characters move naturally
Responsive game cameras and environments across phones, tablets, and desktops
Building interactions simple enough for a 2-year-old, interesting enough for a 6-year-old, and still enjoyable for an adult
Exploring how family members in different locations might eventually share the same virtual world
Built With
TypeScript, Vite, HTML/CSS, Phaser 3, illustrated PNG/WebP assets, Recraft, Rive, GitHub Pages, Vitest, and an optional Cloudflare Worker for shared layout data.
What I Learned
Character animation is its own discipline. I learned about sprites, sprite sheets, walk cycles, frame consistency, rigging, and the difference between moving an image and making a character actually feel like it is walking.
Designing one experience for a 2-year-old, a 6-year-old, and an adult is surprisingly difficult. Interactions need to be immediately understandable for a toddler without becoming boring for everyone else.
Environment design and responsive framing can be harder than traditional application UI.
A world that feels right on desktop may require a fundamentally different camera and composition on a phone.
Artwork and gameplay logic need to remain separate so environments can evolve without breaking movement and interaction.
Small details such as movement speed, scale, depth, animation, and familiar landmarks have an outsized effect on whether a virtual place feels alive.
EXP-004Live
Payson Football
Game-day information shouldn't be scattered across multiple places. Find schedules, locations, weather, and team updates in one place.
Open
Why I Built It
I wanted one place where parents and grandparents could quickly see football schedules, game locations, weather, and other game-day information—especially when they're following multiple kids or grandkids.
What I Was Exploring
Using simple structured TypeScript files instead of standing up a database
Adding game-specific weather based on kickoff time and venue coordinates
Maps and calendar integrations
Responsive schedule design for families checking information on phones
Building an electronic waiver flow for a real seasonal need
Connecting a real custom domain to a deployed application
Built With
Next.js, React, TypeScript, Tailwind CSS, Open-Meteo, Vercel, Vercel Blob, pdf-lib, Google Maps/calendar integrations, and Porkbun for the custom domain and DNS configuration for paysonfootball.com.
What I Learned
Real users expose problems prototypes don't—especially on phones.
Simple structured data files can be enough when the use case does not justify a database.
Weather APIs introduce real product constraints such as forecast windows and missing venue coordinates.
iPhone controls sometimes require different interaction patterns rather than simply styling the desktop control.
A lightweight storage and admin solution can be enough for a temporary seasonal workflow such as electronic waivers.
Temporary needs do not always justify permanent product complexity.
I learned how domain registration, DNS records, Vercel hosting, SSL, and a real public domain fit together by connecting paysonfootball.com through Porkbun.
EXP-005Experiment
FairwayCast
Weather apps tell you the forecast, not whether it's worth playing. Turn today's conditions into a simple golf recommendation.
Open
Why I Built It
I wanted a better way to decide whether I should play golf on a particular day. Weather apps gave me the forecast, but I still had to interpret the temperature, wind, rain, UV, and other conditions myself.
What I Was Exploring
Turning raw hourly weather into a simple golfer-facing YES / MAYBE / NO recommendation
Combining golf-course search with location-based forecasts
Evaluating conditions around an actual tee time and six-hour round rather than an entire day
Rule-based recommendation logic instead of AI or a backend
Mobile-first UI after the original desktop-first version failed on iPhone
Hosting a client-only React application on GitHub Pages
Built With
Vite, React, TypeScript, Tailwind CSS, Open-Meteo, OpenStreetMap Nominatim, and GitHub Pages.
What I Learned
A small set of weather rules can turn a lot of raw forecast data into a surprisingly useful decision.
A desktop-first interface does not automatically become a good mobile experience.
Native iOS date and time controls can require special handling to prevent overflow.
GitHub Pages needs the built Vite output rather than the project source.
Rounding and simplifying forecast information made it easier to understand than displaying unnecessary precision.
EXP-006Experiment
ChordFrame
Playing guitar shouldn't mean stopping to scroll. Keep the entire song visible from the first chord to the last.
Open
Why I Built It
I wanted to play guitar and sing through an entire song without taking my hand off the guitar to scroll through chords and lyrics.
What I Was Exploring
Automatically fitting an entire song on one screen
Multi-column layouts, typography, and fullscreen performance views
Parsing real-world chord sheets
Transposing chords without destroying chord-over-lyric alignment
Collapsing repeated verses and choruses
Creating a personal songbook stored entirely in the browser
Shifting the experience from “edit a song” toward “open a song and play”
Built With
Vanilla HTML, CSS, and JavaScript, localStorage, and GitHub Pages. Originally prototyped in Python and Streamlit before being rebuilt as a static browser application.
What I Learned
The real problem wasn't displaying chord sheets; it was fitting them into the flow of actually playing music.
Columns, typography, repetition, and information density mattered more than adding editing features.
If the job is playing, the editor should get out of the way.
Chord transposition only works if alignment survives the key change.
A quick Python prototype can be useful for learning, but a simple static application was a better fit for something intended to sit on a music stand.
EXP-007Experiment
ClosetCast
Knowing the temperature isn't the same as knowing what to wear. Get clothing recommendations based on the conditions you'll actually experience.
Open
Why I Built It
Weather apps tell you the temperature, but they don't tell you what to wear. I wanted to explore whether weather, personal style, and the clothes someone already owns could become a useful daily recommendation.
What I Was Exploring
Weather-aware outfit recommendations
Rule-based scoring using temperature, rain, UV, wind, occasion, mood, and style preferences
Turning forecast data into a single useful dressing insight
A calm daily recommendation instead of presenting too many competing options
Client-only persistence with localStorage
How much UI could be removed while keeping the idea useful
Built With
Vanilla HTML, CSS, and JavaScript, Open-Meteo, localStorage, custom SVG garment illustrations, and GitHub Pages.
What I Learned
Recommendation engines can become complicated much faster than the interface should.
The more detailed the scoring became, the more important it was to simplify what the user actually sees.
One clear recommendation often worked better than multiple competing looks.
Remembering preferences and reducing first-visit friction mattered more than adding additional controls.
Collecting feedback is easy; turning that feedback into a real learning loop is a separate experiment.
EXP-008Experiment
TimeFrame
Dates shouldn't just mark time. Discover the people and events that make every day in history worth remembering.
Open
Why I Built It
I wanted to experiment with connecting two different APIs and combining their data into something fun rather than building another traditional utility.
What I Was Exploring
Calling two unrelated public APIs directly from the browser
Combining history and museum data around a single shared key: a year
Running multiple requests in parallel while allowing one source to fail independently
Cleaning and reshaping API responses that were not designed to work together
Handling CORS, timeouts, missing data, and empty-result states
Shipping a small interactive experiment using only static files
Built With
Vanilla HTML5, CSS3, and JavaScript with no framework or bundler. Google Fonts (Cinzel and Lora), the Wikipedia MediaWiki Action API, Wikipedia REST Summary API, The Met Collection API, a Python 3 standard-library local proxy server, public CORS-proxy fallbacks, and GitHub Pages. No npm packages, database, backend framework, tests, or GitHub Actions.
What I Learned
Two unrelated APIs can become one coherent experience when they share a useful key—in this case, a year—and their responses are reshaped around the same user intent.
Fetching two APIs is the easy part. CORS, timeouts, HTML parsing, missing images, and empty states are where the real work appears.
Promise.allSettled is useful when independent data sources should not be allowed to break the entire experience.
Wikipedia's useful event data required parsing rendered HTML rather than simply consuming clean JSON.
The Met needed a wider date range and image filtering before the results felt complete.
Static hosting is simple until an API blocks browser requests, which made local proxying and CORS fallbacks part of the experiment.
Independent error states were more useful than treating the whole page as one loading operation.
Responsive CSS alone was enough to turn the two-panel desktop experience into a usable mobile layout.

Built from Curiosity

About Big Sand Labs

Big Sand Labs is where ideas are explored through software. Every experiment begins with a real problem, a simple question, and a willingness to learn. Some experiments remain experiments. The most useful ideas become products worth sharing.

Build What Matters.

Every experiment begins with curiosity. The good ones earn a future.

Observe

Experiment

Share

Built from Curiosity

SwingTrader

PokeScout

PorchLight

Payson Football

FairwayCast

ChordFrame

ClosetCast

TimeFrame

About Big Sand Labs