DEV Community: Botgauntlet

How much to charge per night on Airbnb in December: which empty dates to hold, raise or lower

Botgauntlet — Mon, 19 Oct 2026 22:27:22 +0000

Note: I used an AI assistant (Claude) to help write this article. The example property is invented. These are rules of thumb, not predictions, and they do not guarantee more bookings or higher income. I am not an accountant.

December is a month when many hosts feel pressure about empty nights and lower the price on every empty date. In my view that is often a mistake. Here is a simple way to sort the dates first.

Take your calendar for the month and mark every empty night. Then sort each empty night into one of three groups.

Holiday window. Empty nights inside roughly 22 December to 2 January. Demand for these dates is often strong, so discounting them early can give money away. A reasonable rule is to hold the price or raise it by 10 to 15%, and to avoid discounting them early. School holidays differ by country and year, so check the dates for the countries your guests come from.
Short gaps. An empty gap of 1 or 2 nights between two stays is hard to fill at full price, because many guests want longer stays. A reasonable rule is to lower the price by about 10% or to allow a 1-night stay for those dates.
All other empty nights. If they are more than 14 days away, a small discount of about 8% is a mild test. If they are closer than 14 days, a larger discount of about 12% is a reasonable rule of thumb (my own assumption, not data), because the chance to fill them shrinks every day.

Worked example (invented property, 31 December nights):

22 nights are empty
Holiday window: 22 to 27 December and 30 to 31 December, so hold or raise those
Other empty nights from 8 to 21 December: lower by 8%

Before you lower any price, check the break-even price for your property (the minimum average price that covers cleaning, commission and fixed costs, which I explained in my previous article). That number is the average you need over the whole period, not a minimum for every night. A discounted night that still covers commission and cleaning is better than an empty night. The risk is discounting so many nights that your average falls below the break-even price; then the month as a whole loses money.

What these rules do not do: they do not know your local events, your competitors, or your reviews. Add your own dates by hand, such as a festival or a conference.

I am testing a small desktop tool that applies these rules to a booking export and prints a December list like the one above. It is not built yet. There is a sample report on invented data and a waiting list: https://stayledger-515.pages.dev/?src=devto

Which of the three groups is largest on your own December calendar?

Etsy profit per order: a worked example and the formula (after fees, shipping and product cost)

Botgauntlet — Fri, 16 Oct 2026 13:24:42 +0000

Note: I used an AI assistant (Claude) to help write this article. The numbers are an invented example and I ran the arithmetic. The fee rates below are examples, not current official fees. Fees differ by country and change often, so check your own. This is not tax advice.

Shop dashboards show revenue and fees, but few sellers see profit per order after product cost, shipping you pay, fees and refunds. Here is the calculation, step by step.

Invented example, one order of a small item:

Item price 11.00, shipping charged to the buyer 3.00, so the order total is 14.00
Cost of the item (materials and packaging) 3.50
Shipping you pay to the carrier 4.20
Example fees: transaction 6.5% of the total, payment processing 3% of the total plus 0.25, listing 0.20

Fees: 0.065 x 14.00 = 0.91; 0.03 x 14.00 + 0.25 = 0.67; listing 0.20. Total fees 1.78.

Profit = 14.00 - 3.50 - 4.20 - 1.78 = 4.52.

Now the cases that quietly eat profit:

Offsite ads fee. If the platform charges 15% of the total on an order that came from its ads, that is 2.10 more. Profit on that order falls to 2.42.
Refund. If you refund the order and still paid shipping, you lose the 4.20 and possibly part of the fees, depending on the platform. If the item is not returned, you also lose its cost (3.50). That one refund cancels almost all of the profit (4.52) of a normal order.

So averages hide the picture. Compute profit per order and then group it by product. Sellers often find one or two products that sell often and earn almost nothing.

Reverse price: what item price gives a 35% margin on the order total?

The example order above has a margin of 4.52 / 14.00 = 32.3%. To reach 35% on a normal order (no ads, no refund), with the same 3.00 shipping charged to the buyer:

fixed per order = listing + processing fixed + item cost + shipping paid = 0.20 + 0.25 + 3.50 + 4.20 = 8.15
percentage fees = 6.5% + 3% = 9.5%

order total = fixed / (1 - percentage fees - target margin) = 8.15 / (1 - 0.095 - 0.35) = 14.68
item price = order total - shipping charged = 14.68 - 3.00 = 11.68

Check: 14.68 x 0.905 - 8.15 = 5.14, and 5.14 / 14.68 = 35%. So this item would need to list at about 11.68 instead of 11.00 to reach a 35% margin on a normal order.

Practical steps:

Export your orders as CSV from your shop dashboard.
Add columns for item cost and shipping paid.
Compute fees with your own rates and subtract.
Group by product, sort by profit per order, and check the bottom three.

I am testing a small tool that does this from an order CSV, with an editable fee table. It is not built yet. There is a sample report on invented orders and a waiting list: https://orderledger.pages.dev

Which cost do you find hardest to track per order?

I tested my backtest validator on 6,000 fake datasets. It lied once.

Botgauntlet — Wed, 14 Oct 2026 19:31:26 +0000

Note: I used an AI assistant (Claude) to help write this article and the code. The numbers come from my own locked simulation run, not live trading. This is not financial advice.

Update (16 Oct): A reader (thanks, Arhan Canli) pointed out that my description of the extra cost was misleading. In the tool, the 0.2% per-trade cost is subtracted in only one criterion (mean after cost above zero). The t-statistic and the sign-flip p-value are computed before cost. With the cost applied before the t-test, the pass rates at true edges of 0.15%, 0.20% and 0.30% would be about 0.0%, 0.2% and 16.3%, instead of the 15.6%, 50.4% and 98.2% reported below, which are accurate for the tool as it currently is. So Result 2 describes a tool that tests significance before cost and only checks the sign after it. I am changing the tool so the t-test uses after-cost returns, and I will rerun the calibration under a new locked protocol (version 2).

I built a small Python tool that checks a list of backtest trades against eight strict criteria and prints PASS or FAIL. Before I show it to anyone, I wanted to know one thing: how often does it say PASS when there is nothing there?

So I locked a protocol first (hypothesis, scenarios, and the rule for what counts as acceptable), then ran it once. No tuning after seeing the numbers.

The setup

Each fake dataset is a series of dates with 2 trades per date, return = true mean + noise. I made 500 datasets per scenario, 12 scenarios, 6,000 datasets in total.

Six scenarios have no edge at all:

N1 to N3: plain Gaussian noise with 200, 100 and 400 dates
N4: fat-tailed noise
N5: noise plus 3 planted huge winning dates
N6: an edge in the first half of the data that reverses in the second half

Six scenarios have a real edge of 0.05%, 0.10%, 0.15%, 0.20%, 0.30% and 0.50% per trade, with 200 dates. The tool also requires the mean to stay positive after an extra 0.2% cost per trade (see the update above for what that does and does not test).

Result 1: false passes on no-edge data

Out of 3,000 no-edge datasets, the tool said "all criteria passed" once. It happened in N1: 1 of 500, or 0.2% (95% interval 0.0% to 1.1%). The other five scenarios gave 0 of 500, including the planted outliers and the half-and-half edge. My rule was that up to 1% false passes is acceptable. The upper end of that interval is slightly above 1%, so one honest reading is "probably under 1%, not proven".

Which criteria do the work? In N1 the strict t-statistic (at least 3) passed in only 0.2% of datasets, and "still positive after removing the 3 best dates" passed in 29.6%. The simple checks (first half positive, second half positive, median positive) pass about half the time on pure noise, which is why none of them is enough alone.

Result 2: how big must a real edge be?

Share of datasets with a true edge that passed all criteria (200 dates, noise sd 1% per trade):

0.05% per trade: 0.4%
0.10%: 3.6%
0.15%: 15.6%
0.20%: 50.4%
0.30%: 98.2%
0.50%: 100%

The tool is conservative about small edges, but it is not safe below the cost line. After the extra 0.2% cost, an edge of 0.15% per trade is a net loss, yet the tool passed 15.6% of those datasets, and 3.6% at 0.10%. Those are false passes on strategies that lose money after cost, well above my 1% rule. So the 1% false-pass result only applies to pure noise, not to weak real edges that cost more than they earn. At 200 dates a real edge needs to be about 0.2% to 0.3% per trade before it is detected reliably. That is a limit of this tool, and I plan to examine it before I release anything.

What this does not show

This is a simulation with independent days. Real trades have regimes and clustering, so real false-pass rates can be higher. I ran the tool at its default settings, and the 500-dataset runs use fewer permutations (2,000) than the real tool (10,000).

I can post the locked protocol and the raw output in a comment if anyone wants to check the numbers.

I am keeping a waiting list for the tool at https://botgauntlet.com. Which of these checks do you already run on your own backtests?

The average nightly price your rental needs to break even (with the formula)

Botgauntlet — Mon, 12 Oct 2026 12:16:50 +0000

Note: I used an AI assistant (Claude) to help write this article. The formulas and the example numbers are checked by running them. The example property is invented. The result is before income tax. I am not an accountant and this is not tax advice.

Most hosts know their nightly price. Fewer know the average price below which the whole period loses money. Here is a simple way to calculate it from numbers you already have, in any spreadsheet.

What you need, for one property and one period (for example January to today):

Nights booked (N)
Number of stays (S)
Platform commission as a fraction (c). For example 15% = 0.15. Check what your platform really charges you.
Cleaning cost you pay per stay (k). If guests pay you a separate cleaning fee, use the cost minus that fee, or leave the fee out of your income.
Fixed costs for the same period (F): rent or mortgage share, utilities, internet, insurance, supplies

The formula:

break-even price per night = (F + S x k) / ((1 - c) x N)

It answers: at the occupancy I really had, what average price covers all costs?

Worked example (invented property):

43 stays, 139 nights booked, so S = 43 and N = 139
Commission 15%, cleaning 25 per stay, fixed costs 3,877
Cleaning total = 43 x 25 = 1,075
Costs to cover = 3,877 + 1,075 = 4,952
Break-even = 4,952 / (0.85 x 139) = 41.91 per night

If the average price you charge is 71.95, the gap is 30.04 per night. If your average price were 40, you would lose money on average, even though the calendar looks busy.

Three things to watch:

The number depends on occupancy. If you book fewer nights next period, N drops and the break-even price rises. Recalculate every month.
Commission may also apply to cleaning fees on some platforms. Put the real figure in c.
Do not count nights that were blocked by you or by the owner as booked nights.

What to do with it: treat 41.91 as the average price you need over the whole period, not as a minimum for every single night. Fixed costs are paid whether a night is booked or empty, so a discounted night that still covers commission and cleaning adds money compared with an empty night. For a one-night stay with a 25 cleaning cost and 15% commission, the lowest price that does not lose money on that stay is 25 / 0.85 = 29.41. The danger is not one discounted night; it is a habit of discounting so many nights that your average falls below 41.91. Then the period as a whole loses money.

I am testing a small desktop tool that does this calculation for several properties at once from a booking export, plus a December empty-night review. It is not built yet. There is a page with a sample report on invented data and a waiting list: https://stayledger-515.pages.dev

I would like to hear which cost you forget most often when you calculate your own break-even.

I locked my test criteria before running them. My trading bot failed.

Botgauntlet — Thu, 08 Oct 2026 18:22:38 +0000

I built a Python paper-trading bot for crypto spot markets. The backtest looked fine. Then I tested it the strict way, and it fell apart. This is what the strict way looks like, and what it found.

The rule: lock the criteria before you look

Before each test I write down the hypothesis, the data, the metric and the pass/fail thresholds. I hash the file (sha256). The test script refuses to run if the hash does not match. After that I get one run. No tweaking the threshold after seeing the result.

It sounds bureaucratic. It is the only thing that stopped me from fooling myself, because I tried a lot of ideas and some of them looked good at first glance.

Result 1: the bot had no edge before costs

Update (same day): a reader pointed out that treating 3,314 trades as independent understates the uncertainty. Resampling whole entry days (393 clusters), the pre-cost mean of -0.07% per trade has a 95% interval of about -0.56% to +0.41%, and the net mean of -0.37% has about -0.86% to +0.10%. So the honest reading is: no evidence of an edge before costs, costs of about 0.30% per trade are certain, and the 81%/19% split below is not statistically supportable. This check was done after the fact, not pre-registered.

I replayed the bot's engine on history: 3,314 simulated trades.

Profit factor before any costs: 0.979
After slippage: 0.949
After fees: 0.894

So the signal itself was already slightly negative (about -0.07% per trade), and costs of about 0.30% per round trip did the rest. About 81% of the total loss was cost, 19% was the signal.

The shape of the trades was also a trap. Only 25.3% of trades won, with a payoff of 2.63 to 1. Breakeven needed 27.5% winners. We were 2.2 points short, and no amount of stop tuning changes that if entries are no better than random.

Result 2: the "random entries beat the bot" finding was my own bug

At one point a control showed random entries doing much better than the bot: profit factor 1.69 against 0.89. I almost wrote it up as a discovery.

I locked a follow-up test to find out why. Answer: the random entries were drawn from a window of plus or minus 14 days around each bot entry. The bot buys after a price rise by construction, so random entries placed before it were buying the same rise cheaper. Random entries placed after the bot entry:

Random before: average +0.277 R, profit factor 1.69
Random after: average -0.063 R, profit factor 0.875
The bot: average -0.068 R, profit factor 0.894

The advantage was look-ahead in my control group, not a flaw in the bot. A placebo test is only useful if the placebo is clean.

Result 3: survivorship explained every false positive

Momentum, rotation and several other ideas looked good on today's list of coins. On a point-in-time universe that includes coins that were later delisted, they vanished. In my own post-mortem, the choice of universe explained all of the false positives I found.

Result 4: the effect sits in a handful of episodes

When the "good" result survived a basic test, I removed the best 5% of days or the top few episodes. In several cases the effect went to zero or flipped sign. The number of independent events was in the tens, even though the table showed thousands of rows, because rows from the same day are not independent.

What I took from it

Write the pass/fail criteria first. Hash them. One run.
Test against a placebo, and check that the placebo is clean.
Check the result without its best days.
Count independent events, not rows.
Include delisted instruments.
Stress the costs. Most small effects are smaller than the fee.

I turned this method into a small command-line toolkit, called BotGauntlet: you lock your criteria, run the tests on your own trade list, and get a plain PASS/FAIL report. It will most likely tell you your idea does not work, which is the point. It is not signals and not financial advice. I am collecting a waitlist at https://botgauntlet.com and I would like to hear which of these checks you already run.

Disclosure: the code and analysis were developed with AI assistance (Claude). All numbers above come from my own pre-registered runs on historical data, a simulation, not live trading. Trading involves risk of loss.