DEV Community: Juan Carlos Isaza

From idea to MVP: launch your product in 2 weeks with Python | Xiliux Blog

Juan Carlos Isaza — Fri, 23 Oct 2026 18:38:51 +0000

You have an idea. The temptation is to build it "complete" before showing it to anyone. It's the most expensive mistake you can make: you spend months on features that maybe nobody wants. An MVP (Minimum Viable Product) turns that around.

What an MVP is (and isn't)

An MVP is the smallest version of your product that lets you validate a hypothesis with real users. It isn't a fake prototype nor the final product trimmed down: it's just enough to learn whether people want it.

What an MVP should NOT have:

An elaborate admin panel.
Multiple "just in case" integrations.
Optimizations for a scale you don't yet have.
Every feature the competition has.

What it should: the core flow that solves the problem, and a way to measure whether it works.

Why Python speeds this up

A modern Python stack lets you build a functional MVP in 1–2 weeks instead of months:

FastAPI for the logic and the APIs: fast and with automatic validation.
NiceGUI for the interface without writing JavaScript (see this article).
SQLite or PostgreSQL for the data: start simple, migrate when you need to.
Deployment on a modest VPS behind nginx.

A single developer can cover backend, frontend, and deployment, without coordinating three specialists.

The process

Define the hypothesis: "users will pay for X to solve Y".
Cut without mercy: what is the minimum flow that tests that?
Build fast with tools that don't slow you down.
Launch to real users and measure.
Iterate on what you learned.

The goal isn't perfect code: it's learning cheap. An MVP that tells you "this doesn't work" in two weeks saves you months.

Do you have an idea to validate?

At Xiliux I develop MVPs in Python from end to end, with fixed price and timeline. Tell me your idea and I'll tell you how to turn it into a viable product in weeks: get a quote for your MVP.

Need something like this built? At Xiliux we build custom MVPs and tools in Python and Rust. See our services.

RAG explained: how to give an LLM your own information | Xiliux Blog

Juan Carlos Isaza — Fri, 23 Oct 2026 18:16:52 +0000

A language model knows a great deal about the world, but knows nothing about your company: your manuals, your policies, your products. And if you ask it about something it doesn't know, it may invent an answer that sounds convincing. RAG (Retrieval-Augmented Generation) solves both problems.

The idea

Instead of expecting the model to "already know" your information, you give it to it at the moment of the question:

Index your documents: split them into fragments and turn them into embeddings (numeric vectors that capture the meaning).
When a question comes in, search for the fragments most similar to that question.
Pass the LLM the question together with those fragments and ask it to answer using them.

The model no longer guesses: it answers from a real context that you control. And you can ask it to cite where each fact came from.

The pattern in Python

# 1. Indexado (una vez): fragmentos -> embeddings -> base vectorial
#    (con librerías como sentence-transformers + FAISS, o un servicio gestionado)

# 2. En cada pregunta: recuperar los fragmentos relevantes
fragmentos = base_vectorial.buscar(pregunta, k=4)
contexto = "\n\n".join(fragmentos)

# 3. Generar la respuesta con el contexto
from anthropic import Anthropic
client = Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system="Responde SOLO con la información del contexto. Si no está, dilo.",
    messages=[{
        "role": "user",
        "content": f"Contexto:\n{contexto}\n\nPregunta: {pregunta}",
    }],
)
print(resp.content[0].text)

Note the instruction in the system prompt: asking it to answer only with the context and to admit when it doesn't know is what drastically reduces hallucinations.

What is it good for?

Support assistants that answer with your real documentation.
Internal search in natural language over your manuals or wikis.
Onboarding: a chatbot that knows your processes.

Details that make the difference

How you split the documents (chunking) has a big effect on quality.
Good embeddings and a suitable vector database matter more than the model.
Citing the sources builds trust and allows verification.

RAG is today one of the most cost-effective ways to apply AI in a business: you retrain nothing, and the assistant improves just by updating your documents.

Want an assistant with your data?

At Xiliux I build RAG systems in Python from end to end. Tell me what information you want to put to work: contact.

Automate repetitive tasks with a Python bot | Xiliux Blog

Juan Carlos Isaza — Thu, 22 Oct 2026 18:38:39 +0000

Every manual, repetitive task you do each week is time (and money) a Python script can recover for you. Automation isn't just for large companies.

First: what is worth automating?

Look for repetitive, rule-based, and frequent tasks. Some common examples:

Downloading and consolidating reports every morning.
Copying data between a website and a spreadsheet.
Sending reminders or alerts.
Watching prices or changes on a page.

A rule of thumb: if you can explain the task as a list of steps with no exceptions, it can probably be automated.

The Python ecosystem's tools

requests / httpx to talk to APIs and websites.
BeautifulSoup / Playwright for web scraping (Playwright when the page loads with JavaScript).
pandas to transform data.
APScheduler or cron to run it on a schedule.
Telegram or Discord bots to receive alerts where you already are.

A minimal example

Watch a page's title and alert if it changes:

import requests
from bs4 import BeautifulSoup

def title(url):
    html = requests.get(url, timeout=10).text
    return BeautifulSoup(html, "html.parser").title.string.strip()

previous = title("https://example.com")
# ...run by cron every hour...
current = title("https://example.com")
if current != previous:
    print("Changed!")  # here you would send a Telegram message

From script to reliable bot

A script that runs on your laptop is a good start, but a reliable bot lives on a server, logs what it does, handles errors (retries, timeouts), and alerts you if something fails. That leap —from experiment to a tool you trust— is where a developer adds the most value.

Got a task you hate doing by hand?

It can probably be automated. Tell me what it is and I'll tell you how to approach it: contact.

Need something like this built? At Xiliux we build custom MVPs and tools in Python and Rust. See our services.

NiceGUI: build a web application in Python without writing JavaScript | Xiliux Blog

Juan Carlos Isaza — Thu, 22 Oct 2026 18:19:17 +0000

If you know Python but the frontend holds you back, NiceGUI is one of the best pieces of news of recent years: it lets you build complete web applications —with buttons, forms, charts, and navigation— using only Python.

What is NiceGUI?

It's a framework built on top of FastAPI (backend) and Quasar/Vue (frontend). You write Python; NiceGUI generates the interface in the browser and keeps the state synchronised for you. You don't need HTML, CSS, or JavaScript to get started.

How simple it is

An app with a button that shows a message is literally four lines:

from nicegui import ui

ui.button('Greet', on_click=lambda: ui.notify('Hello!'))

ui.run()

The hierarchy of the interface is expressed with context managers, which reflect how the elements nest:

with ui.card():
    ui.label('Sign in').classes('text-xl font-bold')
    user = ui.input('User')
    password = ui.input('Password', password=True)
    ui.button('Enter', on_click=lambda: sign_in(user.value, password.value))

Adding reactive state, forms, tables, or routes (@ui.page('/panel')) is just as direct.

What is it ideal for?

MVPs and prototypes: validate an idea in days, not weeks.
Dashboards — internal ones and data panels.
Internal tools for your team, without setting up a separate frontend.
Demos of AI models or scripts that need an interface.

When is it NOT the best option?

NiceGUI renders on the client, so for sites where the content's SEO is critical (a blog, a public landing page that has to rank) it's worth complementing it with good meta tags and structured data, or considering server-side rendering. For applications, dashboards, and internal tools it's an excellent and highly productive choice.

Performance and deployment

A NiceGUI app is deployed like any FastAPI/Uvicorn app, usually behind nginx with systemd. Serve the static files from nginx and use ui.run(show=False) in production so as not to open a browser on the server.

Want an app like this?

This very portfolio is built with NiceGUI. If you need an MVP, a dashboard, or an internal tool in Python, write to me.

Need something like this built? At Xiliux we build custom MVPs and tools in Python and Rust. See our services.

How to integrate an LLM (Claude or GPT) into your Python application | Xiliux Blog

Juan Carlos Isaza — Wed, 21 Oct 2026 18:44:48 +0000

Integrating a language model (LLM) into a Python application is easier today than it looks, and it opens the door to chatbots, internal assistants, data extraction, and natural-language automation. In this guide you'll see the complete pattern, with real code.

1. Choose the provider

The three most used are Anthropic (Claude), OpenAI (GPT), and Google (Gemini). They all expose an HTTP API with an official Python SDK, and your app's logic barely changes between them. In the examples I'll use Claude, but the pattern is identical in the others.

Install the SDK and store your key in an environment variable, never in the code:

pip install anthropic
export ANTHROPIC_API_KEY="your-key"

2. The minimal call

The pattern is always the same: you send a list of messages and receive a response.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Summarise in one sentence: photosynthesis..."}
    ],
)
print(resp.content[0].text)

Two important details: resp.content is a list of blocks (check .type before reading .text), and max_tokens limits the length of the response.

3. Streaming for a good experience

In an interface, waiting for all the text to be generated feels slow. Streaming shows the response token by token, as in ChatGPT:

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Write a welcome email."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

For long outputs, streaming also keeps the request from exceeding the connection timeout.

4. Structured output (reliable JSON)

If you need the model to return data in an exact format (for example to store it in a database), ask for a JSON schema instead of parsing free text. This eliminates the most common class of bugs when integrating AI: responses with an unpredictable format.

5. Best practices for production

Control the cost: set a reasonable max_tokens and cache repeated responses. Modern SDKs support prompt caching, which greatly cheapens reused context.
Handle errors and retries: APIs fail; the official SDKs already retry 429 and 5xx errors with exponential backoff. Catch the typed exceptions (RateLimitError, etc.) instead of comparing text strings.
Protect your keys: environment variables, periodic rotation, and minimal permissions.
Choose the model according to the task: a large model for complex reasoning, a smaller and faster one for high-volume classification.

Need help?

At Xiliux I integrate LLMs into Python applications from end to end: chatbots, AI automation, and internal assistants. If you have an idea, let's talk.

When your classifier flickers: hysteresis for signals that oscillate | Xiliux Blog

Juan Carlos Isaza — Wed, 21 Oct 2026 18:24:16 +0000

You have a signal that at every observation tells you which state you're in: a health monitor that says OK or CAÍDO, a connectivity detector, a mode classifier. And near the threshold it oscillates: OK, CAÍDO, OK, CAÍDO, OK. Every change fires something —an alert, a failover, entering or exiting a position— and suddenly your system is shaking from noise, not from a real transition.

It's the same problem your home thermostat has been solving for a century, and the solution has a name: hysteresis. Don't change state until the new one has held.

The rule, in one sentence

A new state is only confirmed after it repeats for N consecutive observations. If the candidate changes or reverts before reaching N, the count resets. The current state stays stable; the flapping is ignored.

I packaged it as a library —hysteresis-state, pure Python, no dependencies— because I kept rewriting it over and over:

from hysteresis_state import HysteresisState

estado = HysteresisState("OK", confirmations=3)

for lectura in stream:                 # "OK" / "CAIDO"
    actual = estado.update(lectura)    # only changes after 3 readings in a row
    if estado.changed:                 # did this reading cause the transition?
        alertar(actual)

Feed it OK, CAÍDO, OK, CAÍDO, OK and nothing happens: no candidate held. It takes three CAÍDO in a row for the change to be confirmed.

The detail that's almost always missing: asymmetric hysteresis

A single threshold has a subtle problem. If you require 3 confirmations to enter failure, you also take 3 to leave it — and sometimes you want exactly the opposite: fall fast to safety, return slowly to risk. It's the behaviour of an electrical circuit breaker: it trips at the first fault, and re-arms with caution.

It's solved by letting the threshold depend on the transition:

# 1 confirmation to fall to "CAIDO", 5 to return to "OK"
conf = lambda desde, hacia: 1 if hacia == "CAIDO" else 5
estado = HysteresisState("OK", confirmations=conf)

estado.update("CAIDO")   # falls instantly
# ...now it takes 5 "OK" in a row to return

Why "averaging" isn't enough

The temptation is to smooth with a moving average and threshold that. It works for numeric signals, but it breaks with discrete states (you don't average OK and CAÍDO), it introduces lag into every transition equally, and it doesn't give you the asymmetry above. Confirmation-based hysteresis is the right tool when what oscillates is a label, not a number.

Where it came from

This was born inside a trading bot. Its regime brain classified the market into trend / range / chaos, and near the thresholds it flapped: each flap froze or reactivated trading, which is exactly what you don't want happening because of noise. Hysteresis calmed it down. But the mechanism knows nothing about markets —it's anti-flapping for any discrete signal—, so I released it.

It's free software. Since August 2026 the code isn't published to registries or on GitHub —we work in security, and having our source extracted would be an argument against the product—: it's delivered on request, signed and with its SHA-256, at contacto@xiliux.com.

Code and tests (with the counting and asymmetry edge cases, verified by mutation): **.

Two ways a backtest lies to you (and how to avoid them) | Xiliux Blog

Juan Carlos Isaza — Tue, 20 Oct 2026 18:41:16 +0000

You test a strategy, or a model, on historical data. The backtest gives a pretty number. And then, live, it doesn't show up. It's almost always one of these two illusions — and both are ruled out with very little code.

I packaged the two corrections as a library: honest-eval, pure Python, no dependencies. They came out of a trading bot, but the rigor has nothing specific to trading.

Illusion 1: the model saw the future

Splitting the data with the classic random train_test_split is correct for independent data. On a time series it's a silent disaster: it puts tomorrow's samples into the training set, and the model "predicts" in the test things that in production wouldn't have happened yet. The metric comes out inflated, and you trust an edge that doesn't exist.

The honest test is always the future: the most recent stretch in time.

from honest_eval import temporal_split

train_idx, test_idx = temporal_split(timestamps, test_frac=0.20, embargo=24)
X_tr, X_te = X[train_idx], X[test_idx]

It returns indices, so you apply it to numpy, pandas or lists alike.

The embargo closes a subtler leak: if your label looks h steps ahead, a training sample within h of the cut already knows part of the test's outcome. embargo=h discards that edge. The metric drops — but it's finally the real out-of-sample one.

Illusion 2: the variant won by luck

You have several variants and you want the best. You pick the one with the highest mean. Mistake: with few samples, that rewards variance, not edge. The noisiest variant usually ends up on top by chance.

Two corrections, both inside select_best_variant:

Pair them. Measure variant and baseline on the same trial and work with δ = variant − baseline. The trial's common variance cancels in the subtraction, and you're left with the signal.

Require a lower confidence bound > 0. Promote a variant only if mean − z·SE > 0: "even being pessimistic within the confidence margin, it stays above the baseline".

from honest_eval import select_best_variant

variants = {
    "chandelier": [0.8, 1.1, -0.2, 0.9, 1.0, 0.7],
    "momentum":   [2.0, -1.5, 3.0, -0.5, 1.2, -1.0],   # high mean, very dispersed
}

elegido = select_best_variant(variants, z=1.6449, min_effective_n=5)
politica = elegido.name if elegido else "baseline"

momentum may have the highest mean and still fail to promote: its dispersion sinks the lower bound. That's exactly what you want to happen — it's the mechanism that rejects the lucky winner.

When recent data weighs more

If the process changes over time, weight by recency. Kish's effective sample size (Σw)² / Σw² keeps a few heavily-weighted samples from passing themselves off as many:

from honest_eval import halflife_weight

weights = [halflife_weight(now - t, halflife=7*86400) for t in exit_ts]
variants = {"chandelier": (deltas, weights)}

They don't create signal — they stop manufacturing it

Neither of them invents edge: that's data and good features. What they do is stop manufacturing it where there is none. They're the minimum for not lying to yourself before risking something real.

It's free software. Since August 2026 the code is not published to registries or on GitHub — we work in security, and having our source extracted would be an argument against the product —: it's delivered on request, signed and with a SHA-256, at contacto@xiliux.com. The honest-eval repo has the description and how to request it.

Why your bot gets a 403 from Cloudflare (and how to harden a ccxt client) | Xiliux Blog

Juan Carlos Isaza — Tue, 20 Oct 2026 18:16:17 +0000

If you automate an exchange with ccxt, sooner or later you'll see it in the logs: short bursts of 403 Forbidden hitting fetch_balance, the OHLCV calls or the earn balance, which clear up on their own after a few minutes. It's not that your API key is wrong. It's the WAF (Cloudflare) that many exchanges put in front of their REST API, challenging something that "looks like a bot".

And your bot is a bot — but a legitimate one, operating your own account against the official API. The problem isn't permissions, it's HTTP client reputation. This is about reducing the WAF's false positives, not evading any access control.

Two layers that mitigate it

I pulled this pattern out of my own OKX bot after several bouts of 403s, and released it as a library: ccxt-resilience (Apache-2.0).

1. Make the WAF challenge less: `harden`

A default ccxt client announces itself as what it is. Setting a browser User-Agent, the Accept-Language header and a generous timeout makes Cloudflare challenge it less often:

import ccxt
from ccxt_resilience import harden

exchange = harden(ccxt.okx({
    "apiKey": ...,
    "secret": ...,
    "password": ...,
}))

harden acts on an already-built client, returns the same object (chainable) and never breaks its construction: if setting an attribute fails, it leaves it as it was.

2. Retry only what you should: `with_retry`

The temptation is to wrap everything in a try/except that retries. It's a trap: retrying a credentials or funds error only wastes time, ends just as badly, and hides logic bugs behind waits.

The key is to retry only the transient — 403/Cloudflare, 429, timeouts — with exponential backoff and jitter, and re-raise the real errors on the spot:

from ccxt_resilience import with_retry

balance = with_retry(exchange.fetch_balance)

ohlcv = with_retry(exchange.fetch_ohlcv, "BTC/USDT", timeframe="1m",
                   attempts=4, base=1.0, max_s=8.0)

An authentication error is re-raised immediately, without retrying. And if the attempts run out, the last exception is re-raised, so your fail-safe handler stays in charge (for example, returning the last cached value).

The wait for attempt i is min(max_s, base * 2**i) + rand()*base: it grows in a bounded way and the jitter keeps multiple clients from retrying in sync.

The classification is explicit

What makes an exception retryable or not is not hidden: it's a function you can inspect and replace.

from ccxt_resilience import is_transient_error

# A Cloudflare 403? Yes. An invalid key? No.
is_transient_error(Exception("403 Forbidden Cloudflare"))   # True
is_transient_error(Exception("invalid api key"))            # False

With ccxt installed it also classifies by exception type (DDoSProtection, RequestTimeout…); without it, by the message. That's why ccxt is a soft dependency: the library works with or without it. And if your case is a different API, with_retry accepts your own retry predicate.

Installation

It's free software. Since August 2026 the code is not published to registries or on GitHub — we work in security, and having our source extracted would be an argument against the product —: it's delivered on request, signed and with a SHA-256, at contacto@xiliux.com. The ccxt-resilience repo has the description and how to request it. It's small, stateless infrastructure; use it piece by piece.

The rounding that makes your bot risk 10 times what you think | Xiliux Blog

Juan Carlos Isaza — Mon, 19 Oct 2026 18:25:16 +0000

Almost every trading bot has one line that decides how much to buy. It usually looks trivial: if I risk 1% of my balance and my stop is 1000 dollars away, the quantity comes out of a division. The arithmetic is grade-school.

What isn't grade-school is making that number fit the exchange's constraints. That's where money is lost, and in ways that don't show up in the logs.

The pattern that multiplies your risk

This is in countless bots, and was in one of mine:

cantidad = max(1, int(cantidad_teorica / contract_size))

The intent is defensive: "never let it come out zero". The effect is the opposite.

If the theoretical quantity comes out to 0.1 contracts, int() truncates it to 0, and then max(1, ...) forces it to one. You've just opened a position ten times larger than the one you authorised.

With concrete numbers: 500 USD balance, 1% risk (5 USD), entry at 50,000, stop at 45,000, 0.01 contracts. The real risk of that single contract is 50 USD — ten times the budget. And it happens silently: the order is accepted, the bot carries on, there's no exception to catch.

The worst part is that it's not a rare case. It happens whenever the balance is small or the stop is wide, that is, exactly when you have the least room for error.

The other two that cost money

Ignoring the minimum notional. The exchange rejects the order for minimum value, the bot logs it as a network error, and nobody realises that signal was never traded. The backtest counted it; the account didn't.

Not reserving for fees. With a tight stop, round-trip fees can be half the real risk. If you size against the distance to the stop and nothing else, you systematically risk more than you think.

How I solved it

I pulled the calculation out of the bot and released it as a library: position-sizing (Apache-2.0, no dependencies).

from decimal import Decimal
from position_sizing import MarketSpec, size_for_risk

spec = MarketSpec(
    amount_step=Decimal("0.001"),
    min_amount=Decimal("0.001"),
    min_notional=Decimal("5"),
)

r = size_for_risk(
    balance=Decimal("1000"),
    risk_fraction=Decimal("0.01"),
    entry=Decimal("50000"),
    stop=Decimal("49000"),
    spec=spec,
    fee_rate=Decimal("0.0005"),
)

if r.ok:
    exchange.create_order(symbol, "market", "buy", float(r.quantity))
else:
    log.warning("sin operar: %s", r.reason)

With ccxt you don't have to write the MarketSpec by hand:

from position_sizing import spec_from_ccxt
spec = spec_from_ccxt(exchange.market("BTC/USDT:USDT"))

Two decisions that matter more than the code

Decimal, not float, and always round down. The bug is born of an accidental truncation. With decimal and explicit rounding, the direction stops being an accident of the type and becomes a decision — and the right decision is down, because the error is asymmetric: going over budget is paid in money, falling short only costs a little performance.

Pure function: it takes a MarketSpec, not an exchange. It tests without a network, works for any exchange and — most importantly — computes the same in backtest as in production. A backtest that assumes fractional positions the market would never have accepted inflates the return; using the same function on both sides, that lie disappears. (That's what another article is about.)

Refusing to trade is also a result

When the market's minimum quantity doesn't fit the risk budget, the library doesn't trade. But it doesn't just return None: it says how much balance would be needed for it to fit.

the market's minimum quantity risks more than budgeted;
5000.00 of balance would be needed

A None forces you to reconstruct the why by reading the code six months later. A reason with the figure inside is read in the log and acted on. Refusing is fine; refusing with an explanation is better.

What it does NOT do

It sizes orders. It doesn't decide when to trade, nor where to put the stop, nor in which direction. It's arithmetic over exchange constraints, not a strategy.

That boundary is deliberate: the part that gives an edge isn't published, but the plumbing we all rewrite wrong is. If your bot has a max(1, int(...)) in the order path, review it today.

I switched off the bot: five strategies, 77,000 candles and zero net edge over fees | Xiliux Blog

Juan Carlos Isaza — Mon, 19 Oct 2026 18:16:17 +0000

I had a trading bot running on a server. I switched it off, and the reason wasn't a losing streak: it was a measurement.

Five strategies, 77,000 one-minute candles of BTC and ETH, fees subtracted. The best of them all returned +0.0135% per trade, with a t = 0.16 statistic.

That's zero. Not "a little": zero.

What was measured, and against what

The five families anyone starting out tends to try:

Momentum — if it went up, it'll keep going up.
Reversion — if it went up too much, it'll come back.
Order-book imbalance (OBI) — if there's more buying pressure than selling, the price moves that way.
Grid — laddered orders that capture oscillation.
Funding carry — collecting the funding rate on perpetuals.

And a volatility-based exit rule of the kind that does have good literature behind it.

Each was measured subtracting the account's real fees, not an ideal fee or zero. That detail is what decides the experiment, and it's the one most often left out.

Why fees flip the sign

A strategy on one-minute candles trades a lot. Each trade pays twice: on entry and on exit. If your gross edge per trade is on the order of thousandths of a percentage point and your round-trip fee is on the order of hundredths, there's no strategy: there's a machine for transferring money to the exchange with intermediate steps.

The fee-free backtest of those same five strategies showed curves that went up. That's the whole trap in one sentence: a backtest without fees doesn't measure a strategy, it measures market noise, and noise always has stretches that go up.

The t-statistic, which is the uncomfortable part

A positive average return says nothing on its own. Flip a coin a thousand times and you'll find streaks. The question is whether your result is distinguishable from chance, and that's what the t-statistic answers: how many standard deviations separate your mean from zero.

With t = 0.16, the answer is that it isn't distinguishable. Not by a long way. To talk about a signal you need to be around 2, and even then with caution given the number of strategies tested —testing five and keeping the best already biases the result upward, so the real bar is higher, not lower.

Another of the strategies gave an information coefficient of +0.00%. It's hard to find a more honest number.

The second measurement: the fixed cost

Even if the edge had been small but real, there was a calculation almost nobody makes: the server costs money every month, edge or no edge. With a small account, the annual cost of the infrastructure exceeded the expected return of a marginal edge.

That is, even in the optimistic scenario —real but tiny edge— the whole system lost money. Not because of the market: because of the bill.

What was done

The bot and the data collector were switched off, and the capital moved to a savings product with a published rate. It yields little and yields what it says.

Switching off isn't giving up. Keeping a system running with an edge measured at zero isn't a neutral position: it pays fees, it pays infrastructure and —most expensive of all— it consumes the attention that would be producing elsewhere.

What I take away

Measure with fees from the very first backtest. If they show up at the end, they'll flip conclusions you already took as settled.
Demand a statistic, not a curve. A rising curve is the easiest thing to produce by accident in this trade.
Count the fixed cost inside the result, not beside it. A system that needs a server has to pay for it before it can be considered profitable.
A negative result is a result. These measurements saved months of tuning parameters on something that didn't exist.

Trusted timestamping: how to date digital evidence so nobody can dispute the date | Xiliux Blog

Juan Carlos Isaza — Sun, 18 Oct 2026 18:20:52 +0000

A digital signature proves two things: what the file is (by its hash) and who signed it (by the key). It doesn't prove a third that almost always matters: when. A signed hash is a point with no date. And without a verifiable date, anyone can sign a document today and claim it's a year old —or the reverse—.

The reflex is to look at the file's date. It doesn't work, for a simple reason: whoever holds the file controls it. The modification date on disk is changed with a command; it isn't a witness, it's a note the interested party writes themselves.

Timestamping solves this by bringing in a third party that cannot backdate.

How a TSA works

The classic standard is RFC 3161. The flow is:

you compute your file's hash (you don't send the file, only its fingerprint),
you send it to a timestamping authority (TSA),
the TSA adds the time from a reliable source and signs the pair (your hash + the time) with its own key,
it returns that stamp.

From there, anyone verifies the stamp with the TSA's public key and confirms two things: that this exact hash existed at that time, and that it hasn't been touched since. The file's content never leaves your side —the TSA only ever sees the fingerprint— which matters when the file is sensitive.

The alternative without a third party: chaining

You don't always want to depend on an external service. The other path is a verifiable append-only log: each new entry includes the hash of the previous one, forming a chain (or a Merkle tree). Inserting something with a past date would force recomputing everything that came after, and that is detectable. It's the mechanism behind transparency logs and, at bottom, the same one a blockchain uses to date its transactions without anyone having to trust a central clock.

The two approaches combine: you stamp with a TSA for the point-in-time proof and chain into an append-only log for the full journey.

What your software must do

If the system produces evidence someone might dispute:

don't use the system date as proof —record it if you want, but don't present it as a certain date—,
stamp each item's hash against an independent time source (a TSA, or a chained log you control but can't rewrite without it showing),
and store the stamp alongside the signature and the hash: the three pieces together are what make digital evidence hold up when the date, and not just the content, comes into dispute.

A hash says what. A signature says who. Timestamping says when —and without the when, the other two prove less than they seem.

What digital chain of custody really is (and what your software must do) | Xiliux Blog

Juan Carlos Isaza — Sun, 18 Oct 2026 18:20:16 +0000

When digital evidence has to hold up before a third party —an audit, a legal process, a forensic review— the question isn't «does the hash match?». It's broader: «how do I know this file is the same one that was collected, that it was produced by who it claims, and that it existed when it claims?». That is digital chain of custody: not a value, but a continuous proof that travels with the file from its origin.

It rests on four guarantees, and they are distinct from one another:

1. Integrity — the content didn't change

This is what the hash gives you: a cryptographic fingerprint (SHA-256, say) that changes completely if a single bit changes. You recompute the hash and compare; if they match, the two copies are identical.

But integrity alone is fragile as proof: if someone can replace the file, they can also recompute and replace the hash. The hash proves two copies are equal; it doesn't prove nobody changed both of them.

2. Authenticity — who produced it

This is where the digital signature comes in: the producer signs the hash with their private key, and anyone verifies with the public one. Now the file isn't just intact, it's attributable. Replacing file and hash is no longer enough: you'd need the signer's private key.

The signature adds a third layer almost nobody looks at: trust that the public key really belongs to who it claims. Cryptography alone doesn't settle that —a PKI, a certificate or a registry does— and it's where most integrity reports fall apart.

3. Verifiable date — when it existed

A hash and a signature are a point with no date. They prove the file is this one and that this person signed it, but not that it existed on Tuesday and not Thursday. For that you need a timestamp: a third party that attests to the date and cannot backdate it. Without one, anyone can sign a document today and present it as a year old.

4. Traceability — who touched it afterwards

The first three describe the file. The fourth describes its journey: a tamper-evident, append-only event log of who collected, received, moved, stored and accessed it, with the date. If that log can be edited without a trace, the chain breaks exactly where nobody looks. A log you can rewrite isn't custody, it's decoration.

What this means for your software

A system that «stores the hash» covers one of the four. One that genuinely sustains chain of custody:

computes and stores each item's hash (integrity),
signs it with a key whose ownership can be verified (authenticity),
stamps it with a time from a trusted third party (date),
and writes every access to an append-only log that can't be edited (traceability).

None of the four is optional if the goal is for the evidence to survive a challenge. And the one most often forgotten is the last, because it's the only one you can't see in the file.

DEV Community: Juan Carlos Isaza

From idea to MVP: launch your product in 2 weeks with Python | Xiliux Blog

What an MVP is (and isn't)

Why Python speeds this up

The process

Do you have an idea to validate?

RAG explained: how to give an LLM your own information | Xiliux Blog

The idea

The pattern in Python

What is it good for?

Details that make the difference

Want an assistant with your data?

Automate repetitive tasks with a Python bot | Xiliux Blog

First: what is worth automating?

The Python ecosystem's tools

A minimal example

From script to reliable bot

Got a task you hate doing by hand?

NiceGUI: build a web application in Python without writing JavaScript | Xiliux Blog

What is NiceGUI?

How simple it is

What is it ideal for?

When is it NOT the best option?

Performance and deployment

Want an app like this?

How to integrate an LLM (Claude or GPT) into your Python application | Xiliux Blog

1. Choose the provider

2. The minimal call

3. Streaming for a good experience

4. Structured output (reliable JSON)

5. Best practices for production

Need help?

When your classifier flickers: hysteresis for signals that oscillate | Xiliux Blog

The rule, in one sentence

The detail that's almost always missing: asymmetric hysteresis

Why "averaging" isn't enough

Where it came from

Two ways a backtest lies to you (and how to avoid them) | Xiliux Blog

Illusion 1: the model saw the future

Illusion 2: the variant won by luck

When recent data weighs more

They don't create signal — they stop manufacturing it

Why your bot gets a 403 from Cloudflare (and how to harden a ccxt client) | Xiliux Blog

Two layers that mitigate it

1. Make the WAF challenge less: harden

2. Retry only what you should: with_retry

The classification is explicit

Installation

The rounding that makes your bot risk 10 times what you think | Xiliux Blog

The pattern that multiplies your risk

The other two that cost money

How I solved it

Two decisions that matter more than the code

Refusing to trade is also a result

What it does NOT do

I switched off the bot: five strategies, 77,000 candles and zero net edge over fees | Xiliux Blog

What was measured, and against what

Why fees flip the sign

The t-statistic, which is the uncomfortable part

The second measurement: the fixed cost

What was done

What I take away

Trusted timestamping: how to date digital evidence so nobody can dispute the date | Xiliux Blog

How a TSA works

The alternative without a third party: chaining

What your software must do

What digital chain of custody really is (and what your software must do) | Xiliux Blog

1. Integrity — the content didn't change

2. Authenticity — who produced it

3. Verifiable date — when it existed

4. Traceability — who touched it afterwards

What this means for your software

1. Make the WAF challenge less: `harden`

2. Retry only what you should: `with_retry`