Active product
ABOUT PROSOCIAL CODINGStudio Principles & Practice
I build software around real work.
I'm Ryan Thomas, founder of Prosocial Coding. My path into software ran through anthropology, teaching and training, direct human services, and nonprofit operations before it became product development.
That experience shapes how I build: understand the workflow before choosing the technology, keep human judgment visible where consequences matter, and design systems another team can actually operate.
Ryan ThomasFounder
Independent studio
Real-world workflows
Human agency
Systems thinking
Product craft
Public accountability
HOW I GOT HERE
Software came last.
Each stage added a constraint I still design around.
01
Anthropology
Observation and context
“Observe the system before redesigning it.”
Anthropology taught me to look closely at how people, institutions, and systems actually function — not just how they’re described.
02
Teaching and training
Instruction and adoption
“Make complex work understandable and adoptable.”
A technically correct solution isn’t enough. People need clear explanations, usable steps, and enough context to make something their own.
03
Direct human services
Safety and consequence
“Treat human consequences as system requirements.”
Work in crisis and community-service settings made communication, discretion, safety, and operational clarity concrete rather than abstract.
04
Grants and nonprofit operations
Process and ownership
“Design for constrained teams.”
Compliance, workflow infrastructure, and limited capacity taught me to account for documentation, accountability, and maintaining systems over time.
05
Software products
Implementation
“Turn those lessons into working systems.”
Software became the way to translate that background into tools people can use, inspect, adapt, and eventually own.
01
Anthropology
Observation and context
“Observe the system before redesigning it.”
Anthropology taught me to look closely at how people, institutions, and systems actually function — not just how they’re described.
02
Teaching and training
Instruction and adoption
“Make complex work understandable and adoptable.”
A technically correct solution isn’t enough. People need clear explanations, usable steps, and enough context to make something their own.
03
Direct human services
Safety and consequence
“Treat human consequences as system requirements.”
Work in crisis and community-service settings made communication, discretion, safety, and operational clarity concrete rather than abstract.
04
Grants and nonprofit operations
Process and ownership
“Design for constrained teams.”
Compliance, workflow infrastructure, and limited capacity taught me to account for documentation, accountability, and maintaining systems over time.
05
Software products
Implementation
“Turn those lessons into working systems.”
Software became the way to translate that background into tools people can use, inspect, adapt, and eventually own.
WHY THIS WORK
The stakes change how the software has to be built.
Much of my work sits close to domestic and sexual violence, survivor advocacy, and the systems around them. In that context, product decisions are not neutral. A default setting, data field, notification, model response, or retention rule can create consequences far beyond the screen.
That is why survivor safety, privacy, informed choice, and human oversight have to be treated as product requirements. The system should make its boundaries clear, collect no more information than it needs, surface uncertainty instead of hiding it, and keep consequential decisions with the people who hold the context.
Safety cannot live only in a privacy policy or disclaimer. It has to show up in the architecture, interface, defaults, data practices, and operating procedures.
I build the systems. Survivors and advocates keep the judgment, context, and choice.
WHAT THAT REQUIRES
Safety principles become engineering requirements.
The point is not to add a safety layer after the product is built. These requirements shape the data model, interface, AI behavior, review flow, and handoff from the start.
01
Principle
Survivor safety first
Consider misuse, coercive access, shared devices, discovery risk, notification exposure, and unintended consequences before optimizing convenience.
Build implication
Safer defaults, bounded notifications, visible escape paths, and conservative data exposure over convenience.
02
Principle
Privacy by minimization
Collect, retain, expose, and share only what the workflow requires. Make access, storage, deletion, and third-party boundaries understandable.
Build implication
Field-level minimization, strict retention windows, clear storage boundaries, and explicit data deletion without lingering custody.
03
Principle
Guardrails around automation
Use AI and automation to support explanation, organization, analysis, and practice without concealing uncertainty or taking consequential judgment away from people.
Build implication
Deterministic boundary gates, surfaced confidence limits, non-autonomous action paths, and mandatory human review before execution.
04
Principle
Transparency at the point of use
Make it clear what the system knows, what it is doing, what it cannot determine, and when human review matters.
Build implication
Context-visible interface state, plain-language runtime disclosure, clear error conditions, and audible boundaries on system inferences.
05
Principle
Reviewable ownership
Document architecture, limits, dependencies, and operating responsibilities so another team can evaluate, maintain, and change the system without hidden assumptions.
Build implication
Modular architecture, vendor-independent codebases, exhaustive handoff documentation, and inspectable operational runbooks.
SELECTED WORK
The principles show up in the products.
The build discipline is easiest to see in the products themselves. Protectly turns a daunting legal process into guided protective-order preparation for Texas survivors. SpeakerFree gives people navigating monitoring or coercive control a way to review the technology around them. Both start from a real workflow and keep human judgment at the center.
Across the current portfolio:
- Real workflows over hypothetical features
- Inspectable boundaries and documented limitations
- Practical AI assistance with human oversight
- Architecture designed for transfer and maintainability
Technical approach:
Modern React and TypeScript, browser and server workflows, structured data and API design, disciplined testing, and deployment configurations chosen to match the actual operational requirement rather than a default stack.
Active product
Sample product UI
Representative synthetic data · Not safety guidance
SpeakerFreeSafety review
Camouflage (C)Quick Exit (Esc)
01
Check context
Tailor your safety plan
Before changing a device
- Same place
- No, somewhere safe
- Physical access
- Yes
- Account access
- Full
- Notifications
- Person of concern may receive alerts
- Goal
- Gathering information
Safety timing
Wait until safer
Device or account changes may be visible to another person.
02
Identify + inspect
Selected device
Ring Video Doorbell
Amazon / Ring · Family-level identification
Photo identification
Explicit user action
Optional cloud requestNearby Bluetooth
Educational BLE view
Browser support requiredRouter review
Open router device list
No LAN scanPhone + account audit
Location and login checklist
Structured reviewData boundary
Safety answers remain in browser memory. Device-photo analysis occurs only after explicit user submission.
03
Review safe options
Safety guidance
ContainedDevice-specific steps are paused
SpeakerFree could not confirm instructions that safely match this device and situation, so it does not guess reset, account, power, or notification behavior.
Timing
Wait until it feels safer
Lower-risk next option
If it is already visible and safe to look, note the exact product name from its label or app without moving, disconnecting, testing, or changing it.
Safety timing
Local
Standard route
Contained
Human review
Pending
Evaluation pipeline
Curated exact-device protocolsGrounded device researchDeterministic admissionFail closed
Test / evaluation path · Independent safety review pending
Check contextIdentify & inspectReview guidancePlan & exit safely
Training
Fictional Practice Session
Supervised voice and text simulation for sensitive crisis workflows.
Decision support
Evidence-Informed Comparison
Systematic rubric evaluation and curriculum decision support.
WHAT I'M WORKING ON NOW
Two tracks. One standard.
A focused product portfolio, paired with selective client work where the fit is strong.
01
PRODUCT DEVELOPMENT
Build and harden original products.
Developing a small portfolio with clear use cases, verified functionality, and documented readiness.
CURRENTCallCraft · SpeakerFree · New concepts
02
SELECTIVE ENGAGEMENTS
Advisory, custom tools, and AI training.
Applied AI strategy, custom tools, and practical training for organizations with a clear implementation need.
FOCUSSafer tools · Stronger workflows · Team capability
DURABLE, REVIEWABLE WORK OVER PROJECT VOLUME.
HOW I WORK
Small by design.
Prosocial Coding is an independent software studio. I work directly from problem framing through implementation — which means fewer handoffs, closer contact with the operating context, and clearer accountability for what gets built.
It also means being candid about fit — willing to say when software isn’t the right answer — and designing every engagement so the client or next owner isn’t permanently dependent on me. The goal is durable, reviewable work, not maximum project volume.
01
Direct collaboration
Work directly with the person shaping and building the system.
02
Fewer handoffs
Keep the operating problem and technical implementation closer together.
03
Clear fit assessments
Be candid about whether software is useful, appropriate, and supportable for the problem.
04
Built for ownership
Design the system, documentation, and handoff so the work can continue without permanent dependency.
