Answers, not angles
Sun position is only useful after it answers a lived question. I kept the solar model underneath and made morning light, afternoon light, plants, and winter the primary outputs.
Sunlit · Product case study
3 minute read · 2026
Will this apartmentactually get light?
I designed and built a browser-based tool that turns an address, window direction, and a few physical constraints into plain-language answers—before someone signs a lease.
- Role
- Product direction · UX · Frontend
- Status
- Public working prototype
- Built with
- React · Vite · SunCalc · Mapbox GL · OpenStreetMap
Renters ask human questions. Most sun tools return geometry.
“Will the room feel bright at breakfast?” is not the same question as “What is the solar azimuth at 9 AM?”
Light can change whether an apartment feels calm, supports plants, or needs lamps all day. But renters usually have to infer that from a compass app, a map, and a short viewing.
Existing tools often stop at simulation. The opportunity was to build a decision tool: keep the calculation rigorous, then translate it into the questions people already use.
Product bet
If the setup feels like describing an apartment—not operating a solar model—people can reach a useful light portrait in a few minutes.
One screen moves from uncertain address to a readable light portrait.
- 1
Locate the apartment and confirm the right result.
- 2
Orient the window with a direction or a wall on the map.
- 3
Read when direct light arrives and what it means in daily life.
Three choices kept technical depth from becoming user friction.
Let people correct the model
An address can resolve to the wrong building and a compass label can feel abstract. The flow keeps candidate selection visible, then lets people click a wall on the map; the map, compass, and direction field stay in sync.
Add precision in layers
The first useful version needed only location, facing direction, and solar geometry. Floor height and the building across came later, without turning the core experience into a technical setup form.
A small translation layer turns several data sources into one answer.
Input
Address · facing · floor · month · time
Model
OpenStreetMap geocoding · SunCalc solar position
Context
Mapbox orientation · optional building obstruction
Answer
Timeline + room depth + four lived-light summaries
The app runs entirely client-side, with no backend. An address is geocoded through OpenStreetMap; the satellite map and building outlines come from Mapbox. When the address is in New York City, it pulls NYC Open Data building footprints and roof heights to estimate the building across automatically; everywhere else, you enter that obstruction by hand.
A shipped prototype—and a clear next question.
What exists now
A public, working web product that accepts real addresses and produces a decision-oriented light portrait, with optional context for floor height and the building across.
What I would validate next
Test the language and setup with apartment hunters, then learn whether a side-by-side Compare apartments flow changes an actual shortlist. That feature is intentionally not claimed as shipped.
What I learnedAccuracy is necessary, but it is not the product. The product is the moment technical evidence becomes a decision someone can trust.
See the decision tool in context.