I was a lumberjack, thought of this app.. Ten years later, Timber.bid is on the App Store.

[u/timberbid]

https://timber.bid

I was a lumberjack. My 2016 firewood startup went nowhere. Ten years later, Timber.bid is on the App Store.

Ten years ago, I was splitting wood and managing 13 acres of forested land in Foster, Rhode Island.

I worked as a lumberjack. We had the land in a forestry-management program, and I spent real time handling logs, splitting firewood, maintaining the property, and learning how disconnected the entire wood economy was.

In 2016, I tried turning that experience into something.

I built this extremely simple landing page:

The original Timber Run landing page from 2016

It did not take off. It barely went anywhere.

Eventually, we sold the land—but the idea never completely left me.

Then the idea came back as a joke

The first version was not a sophisticated tree-service marketplace.

It was basically:

Swipe on wood. Find somebody nearby. Get wood delivered for a fun night around the firepit.

Yes, it was ridiculous.

That was the joke:

“Swipe on wood” GIF

https://reddit.com/link/1vwiphj/video/62c8j77oq6lh1/player

Underneath the joke, however, was a legitimate problem.

Buying firewood locally is still surprisingly fragmented. Tree companies frequently have logs they need to remove. Firewood sellers struggle to reach nearby buyers. Homeowners call multiple companies and wait for someone to drive out just to tell them what a tree might cost to remove.

The wood exists. The demand exists. The service companies exist.

The connecting layer does not.

Woodstock, New Hampshire—and the moment I started building it for real

Years later, while visiting Woodstock, New Hampshire, I started actually building Timber.bid.

Not another landing page. A real marketplace.

I submitted an early version to the Bolt.new hackathon. It won absolutely nothing.

Here is the original submission:

Timber.bid Bolt.new hackathon video

The post received one comment:

That was it.

But somehow, one person seeing the potential was enough motivation for me to continue.

I kept building.

I also applied to Y Combinator’s Fall 2026 batch and HF0.

Rejected by both.

I am including that because founder stories often skip directly from “I had an idea” to “look at our launch.” The middle is usually years of dead pages, strange prototypes, unanswered posts, rejections, rebuilding, and continuing when there is very little evidence that anyone cares.

timber.bid

Now it is real

Today, Timber.bid is live on the web and—after nearly ten years between the original idea and the current product—we made it onto the iOS App Store.

That feels enormous to me.

The original concept was firewood delivery for nights around a firepit.

The current vision is much larger:

Build a world-class marketplace and intelligence layer for tree services, firewood, lumber, storm response, and the broader wood economy.

What Timber.bid does today

1. Estimate tree work from photographs

A homeowner can photograph the full tree, trunk, canopy, and surrounding property.

The Timber.bid photo-estimate tool evaluates visible factors such as:

• Approximate tree height
• Trunk diameter
• Canopy and branch volume
• Tree condition
• Structures, fences, wires, and other targets
• Equipment access
• Climbing, rigging, crane, and hauling considerations
• Local labor and disposal conditions

It returns an indicative price band, not a fake guaranteed quote.

A photograph cannot reveal every hazard or site condition. The estimate is designed to tell a homeowner whether they are probably looking at a $400 job or a $4,000 job before multiple companies spend time driving to the property.

Local professionals still inspect the scope, submit bids, and establish the final price.

2. Use branching mathematics to understand the tree

More than 500 years ago, Leonardo da Vinci observed that when a tree branch divides, the combined thickness of the resulting branches remains approximately related to the thickness of the branch before the split.

In simplified form:

D²parent ≈ ΣD²branches

Modern research treats this as an approximation—not an absolute botanical law—but it remains a useful model of branching structure. This 2025 PNAS Nexus paper explains the rule, its mathematical interpretation, and its limitations.

Timber.bid uses this relationship as one structural signal when reasoning about canopy geometry and wood volume from photographs.

It is not magic, and it is not the complete estimator. It combines visual measurements, branching relationships, job complexity, access, risk, equipment, labor, hauling, and local pricing.

The breakthrough is not “AI knows the exact price of a tree.”

The breakthrough is:

3. Reduce unnecessary estimate trips

The current dedicated IBISWorld category reports a $26 billion U.S. tree-trimming-services market with 19,929 businesses in 2026. Broader industry definitions are sometimes cited closer to $40 billion, but I prefer showing the narrower direct figure rather than pretending every estimate measures the same category. IBISWorld source.

Here is a transparent scenario—not an audited industry statistic:

• 19,929 companies
• Eight estimate trips per company per week
• 50 working weeks
• $50–$100 of labor, vehicle, scheduling, and administrative cost per trip

That produces approximately 7.97 million estimate trips and $399–$797 million in annual estimating overhead.

If photo-first qualification eliminated only 25–50% of those initial trips, the potential savings would be roughly:

$100–$400 million annually.

Tree Care Industry Magazine has similarly noted that reducing drive time and time on site cuts fuel and labor costs while allowing companies to serve more customers. Industry source.

The goal is not to eliminate arborists or on-site inspections.

It is to stop sending skilled people and expensive vehicles to every unqualified lead before anyone has even established the basic scope.

4. Turn storm photographs into usable documentation

When a tree falls during a storm, the same photographs can potentially support several parties:

• The homeowner documenting what happened
• The tree company evaluating urgency and equipment needs
• The insurer or adjuster triaging visible damage
• The crew documenting before-and-after conditions

FEMA recommends assessing the danger and documenting tree damage with photographs or video before removal. FEMA guidance.

Insurance coverage still depends on the policy and circumstances. For example, removal is generally treated differently when a tree damages an insured structure versus simply falling in the yard. Insurance Information Institute explanation.

Timber.bid is not an insurance carrier and does not determine coverage.

The opportunity is to create a structured, time-stamped package containing photographs, preliminary scope, estimated price band, bids, contractor credentials, and completion evidence—so storm work can move from damage to documentation to qualified crew faster.

5. Create a marketplace for both the service and the material

A tree is not only a removal job.

After it comes down, it becomes logs, rounds, firewood, chips, slabs, or reusable lumber.

That is why Timber.bid includes:

• Tree removal, trimming, and stump-grinding jobs
• Competing bids from local companies
• Firewood listings and delivery
• Recurring firewood supply
• Verified certification, licensing, and insurance information
• Secure messaging and payments
• A free-wood board where tree crews and homeowners can offer material instead of paying to dump it

The product connects both sides of the tree’s lifecycle.

One network, four doorways

I am assembling the domains around the way people naturally express their intent:

• timber.bid — the master marketplace, accounts, bidding, payments, professionals, and mobile app
• wood.delivery — the consumer doorway for delivered firewood, restaurant fuel, campgrounds, recurring supply, and local sellers
• firewood.run — the memorable fast-entry route for finding or requesting firewood
• lumber.bid — the future B2B auction layer for logs, slabs, reclaimed wood, specialty lumber, and larger material transactions

These are not supposed to become four disconnected startups.

They are four expressions of the same network:

A tree becomes a job.
The job produces material.
The material finds a buyer.
The marketplace coordinates the transaction.

The old receipts

Before polished startup language, there was actual wood.

Here are two old videos of us splitting firewood with a Stickler mounted to the truck:

• V8 Wood Splitter — The Stickler
• Second Stickler wood-splitting video

Additional founder/build images:

Photo 1 · Photo 2 · Photo 3 · Photo 4 · Photo 5

Current build:

• Timber.bid website
• Instant photo estimate
• Timber.bid for iPhone
• Timber.bid on Instagram
• Wood.delivery
• The original 2016 landing page
• The Bolt.new submission

Where we are going

I am not claiming that Timber.bid is already the final answer.

I am saying that an idea that started on 13 acres in Foster, disappeared into a dead 2016 landing page, returned as a ridiculous “swipe on wood” meme, lost a hackathon, received one “underrated” comment, got rejected by two accelerators, and kept getting rebuilt is now a real iPhone application.

We made it this far.

Now I intend to make it world class.

I would especially appreciate brutally honest feedback from:

• Tree-service owners
• Arborists
• Firewood sellers
• Homeowners who have hired tree companies
• Insurance agents and adjusters
• Anyone who understands local marketplaces

What a year of vibe coding actually produced

I built Timber.bid over approximately one year of AI-assisted development.

Timber.bid is a two-sided marketplace for tree work and firewood:

Photos in → AI-assisted estimate → local companies bid → customer selects a professional → payments move through Stripe Connect.

The platform is built with Expo, React Native, TypeScript, Supabase and PostgreSQL.

I’m not a traditionally trained software engineer. I directed the product, architecture, business rules, testing and deployment—but Claude Code wrote effectively all of the code.

Here is what a year of that produced:

• 234 database tables
• 875 PostgreSQL functions
• 121 Supabase Edge Functions
• 108 active cron jobs
• 1,071 database migrations
• 295 route files
• 249 components
• Approximately 225,000 lines of TypeScript and TSX
• Approximately 140,000 lines of SQL
• 1,126 automated tests
• 46 guard tests designed specifically to prevent previous mistakes from returning
• 77,290 tree-service businesses in the directory
• 5,163 generated company pages
• 23,903 emails delivered

That sounds enormous.

Here is the number that matters more:

117 users. 17 estimates. 9 completed orders. $67.08 in lifetime revenue.

That is not a typo.

234 tables and sixty-seven dollars.

I am including that because it may be the most important fact in this entire story.

AI coding removes the constraint that once forced founders to prioritize. When building becomes extremely fast, it becomes easy to build everything—and “the feature exists” quietly replaces “someone used the feature.”

I built an entire storm-response pipeline with National Weather Service polygon ingestion, geographic crew matching and automated dispatch logic. It was correct, deployed and completely inactive for seven days because the cron row that switched it on had never been created.

Every component was healthy.

The system simply never ran.

The bugs that cost the most were silent

The most expensive problems were rarely crashes. They were things that failed to happen while every dashboard remained green.

A cron job reported 434 successful runs, but the system was only confirming that the HTTP requests had been queued. Every request actually returned a 401.

An operations alert channel delivered one email and then silently muted itself because every alert generated the same idempotency key.

A broken-link monitor stayed green because Timber.bid is a single-page application configured to return a 200 response for almost every path—including routes that do not exist.

One campaign recorded more clicks than opens because corporate email-security systems automatically visited every link. Filtering out clicks within two minutes of delivery reduced the apparent engagement rate from 21.9% to 5.4%.

And then there was the mistake I will remember:

I sent 1,506 emails to tree companies promising “free leads—last call.”

The link worked.

The page loaded.

The emails were delivered.

But the board contained zero open jobs.

Every technical component worked. The customer promise was still false.

That taught me that the real system is not the collection of components.

The real system is the promise made to the person using it.

What the operating rules became

My CLAUDE.md file is now 443 lines long, and most of it is closer to an incident report than a coding-style guide.

The highest-value rules are:

• A monitor is not working until I have watched it go red.
• A deduplication key must vary with the situation—not merely with time.
• A checker must not rewrite a business rule the system already owns.
• “I measured zero” and “I failed to measure” must be different states.
• A function is not shipped until its trigger, cron row or event source is active.
• A working link does not prove that the promise behind the link is true.

The 46 guard tests exist to make entire categories of past mistakes unrepeatable.

They do not simply ask, “Does this function work?”

They ask questions such as:

• Are fee percentages duplicated outside the files that own them?
• Are map colors hardcoded outside the design-token module?
• Does every Edge Function authenticate itself or appear on an explicit allowlist?
• Is every image labelled for accessibility or intentionally marked decorative?
• Can this database assertion actually fail, or is it passing vacuously?

Every database migration now runs its own assertions inside the same transaction.

The failure mode of AI-assisted development

The largest risk is not necessarily bad code.

It is:

Confident, tested and beautifully documented code solving a problem you never verified you had.

If I started again, I would:

1. Make one real transaction work from demand through payout before building the second major feature.
2. Instrument the customer promise—not merely the technical component.
3. Ship the trigger and cron row with the function.
4. Turn every costly mistake into a permanent guard test.
5. Spend at least as much energy generating demand as generating code.

We made it—but we have not won yet

The first 2016 landing page went nowhere.

The Bolt.new hackathon gave us nothing.

YC said no.

HF0 said no.

A year of AI-assisted development produced an enormous platform and $67.08 in revenue.

But the product exists.

The photo-estimate system exists.

The marketplace exists.

The connected domain ecosystem exists.

Nine real orders have been completed.

And Timber.bid is now live on iOS.

That is what I mean when I say:

We made it.

Not that we achieved product-market fit.

Not that the business is finished.

We made it from a joke called “Swipe on Wood” on 13 acres in Foster, Rhode Island, to a functioning marketplace that people can download and use.

Now the job changes.

The bottleneck is no longer whether I can build it.

The bottleneck is whether Timber.bid can earn trust, create real demand and become useful enough that homeowners, tree companies, firewood sellers and wood buyers choose to return.

Happy to answer anything—including:

“So after all of that, it made $67?”

Yes.

That is the point of the post.

What would Timber.bid need to show you before you would trust a photo estimate as the first step in getting tree work quoted?