WinRM quota and PSRP release reliability proof
A public TransScendSurvival post showing the kind of concrete release, automation, and operator-risk analysis that backs the staging/package edge audit offer.
Read proof →Tinyland · enterprise contracting
Software contracting
from a real human.
Twelve years of engineering in service-oriented businesses, FOSS infrastructure, and research-grade build systems. Not an agency, not a faceless AI shop — just one operator who shows up, does the work, and writes the runbook.
Proof points
The work is concrete before the pitch is fancy.
I sell narrow, auditable work first. The first deliverable should make the system clearer even if we stop there.
Package authority and BCR cleanup
Built and documented the Tinyland package-authority model across GitHub, Bazel modules, npm packages, and release workflows.
Practitioner booking and payment work
Shipped real scheduling and payment integration work for service businesses, including audit-first cleanup around booking, Stripe, Venmo, and operator runbooks.
Signed static content and brand-site rollout
Operate a house scaffold for lightweight static brand sites that consume reviewed Tinyland content snapshots without becoming backend authorities.
Current offers
Three concrete services with fixed-scope first deliverables. Every engagement starts with a paid audit so the work is grounded before anyone commits to a retainer.
Staging and package edge audit
A focused pass over build, package, registry, and staging boundaries with a written risk list and first fixed issue.
Who it's for
- Small teams with a working repo that need release or deployment edges made boring enough to sell or operate.
- repo and package authority map
- highest-risk build or deploy fix
- operator handoff note with next actions
manual-invoice-only · signed static projection
Start an inquiry →Static spoke launch pass
A cashflow-first launch pass for a static business or practitioner site using reviewed content projections and explicit contact CTAs.
Who it's for
- Local professionals and small organizations that need a credible site without owning auth, payment, media, or scheduling infrastructure.
- static site scaffold review
- projection-ready offer or service records
- contact path smoke evidence
manual-invoice-only · signed static projection
Start an inquiry →Scheduling and payment capability audit
A practical review of booking, payment, and inquiry handoffs with capability gates before automation work starts.
Who it's for
- Practitioners and service businesses deciding whether to use manual invoices, external booking links, or a managed scheduling bridge.
- current booking and payment flow map
- capability gate checklist
- first safe integration recommendation
manual-invoice-only · signed static projection
Start an inquiry →How engagements work
- 1 Inquiry. Tell me the problem in your own words. One short email is enough — no form fatigue.
- 2 Paid audit. Fixed scope, fixed price, fixed timeline. I send a GnuCash invoice before the paid work starts; you get the diagnostic + a concrete plan even if we don't continue.
- 3 Implementation or runbook. Your call. I implement the cleanup, or hand you a runbook your team can execute.
- 4 Optional retainer. Light support and content updates, monthly cadence, no long-term lock-in.
Paperwork is boring on purpose
One business day reply
If the inquiry fits one of these offers, I send the next questions and a fixed-scope audit proposal.
Manual invoice handoff
No checkout widget yet. First paid work is handled by a portable GnuCash invoice and explicit payment terms.
Calendar every promise
Follow-ups, audit delivery, implementation windows, and handoff calls get dated before the work begins.
Why Tinyland
Real human, not a sales funnel
You email me, I email you back. The same person doing the work writes the proposal and runs the audit.
Fixed-scope first deliverables
Every engagement opens with a fixed-price audit. You see what the work looks like before signing on for more.
Operator-owned, not VC-pressed
Tinyland is operator-owned. I'm not optimizing for an exit; I'm optimizing for boring, repeatable, durable systems.
Runbooks, not dependencies
The deliverable is your team's ability to operate without me. I'll happily disappear when the runbook is good enough.
Ready to scope something?
One short email gets the conversation started. I'll respond with the intake questions for whichever offer fits best.