A newsletter in 2026. I know.
Half the internet keeps insisting newsletters are over — that we are all back to short-form video and disappearing chats and AI summaries of the things we did not have time to read. The other half is shipping a new "stack" every Tuesday, with seven CTAs above the fold, a referral mechanic, and a paid tier you cannot leave without three confirmation modals.
I am not doing either of those things. This is the part where I tell you what this actually is, and what it is not, so you can opt out before the second issue lands and feel zero guilt about it.
The cadence promise
One email per month. Not "weekly with a cheat day." Not "whenever inspiration strikes." Monthly — the last Sunday-ish of each month, plus or minus a week when life happens. Each issue is the kind of thing you can read in under ten minutes on the bus.
If a month goes by and I do not have something I think is worth your inbox, you get nothing that month. Silence is allowed. The worst version of every newsletter is the one that fills space because the founder felt obligated to ship.
What you will get
Honest field notes from a working mobile app engineer. The shape of an issue is roughly:
- Something I shipped recently — what was hard, what I got wrong the first time, what I would do differently.
- A Flutter or Dart quirk I tripped over and the smallest reproducible example I could distill it down to.
- Occasionally a piece on the meta — pricing, contracts, the loneliness of working solo, the calculus of when to take a full-time offer vs keep going.
- A link or two to something I read that actually changed how I work, with one sentence on why.
Topics I will not write about: AI hot takes, prompt engineering listicles, framework wars, or anything I would feel embarrassed to send to a senior engineer I respect. The bar I am aiming for is "would I send this to someone whose technical opinion I genuinely care about, knowing they will read it carefully?" If the answer is no, it does not ship.
A worked example, because we are here
Most of what I write will involve a code snippet at some point — partly because that is how I actually think, and partly because it forces me to be specific. Here is a small one from a Flutter project I shipped last month, where I needed to debounce search input without bringing in a full reactive library:
// Lightweight debouncer — no Riverpod, no Bloc, no third-party deps.
// Cancellable Timer in a Stateful widget. Two-line teardown.
import 'dart:async';
import 'package:flutter/material.dart';
class _SearchFieldState extends State<SearchField> {
Timer? _debounce;
void _onChanged(String value) {
_debounce?.cancel();
_debounce = Timer(const Duration(milliseconds: 300), () {
widget.onSearch(value);
});
}
@override
void dispose() {
_debounce?.cancel();
super.dispose();
}
// ... build() returns a TextField with onChanged: _onChanged
}That is it. Three hundred milliseconds of patience, one cancellable Timer, one disposal. The temptation in 2026 is to reach for a state-management library and an AsyncNotifier and a ref.debounce extension that you found on pub.dev with seventeen stars. Sometimes you need that. Most of the time you need three lines and a dispose().
The kind of writing I want to do here is roughly that shape — small, specific, finishable in one sitting, with a defensible reason for the choice that is not "the framework lifestyle blog told me to."
How to reply
This inbox is real. The Reply-To header on every issue points at my actual personal address — hello@sinnoor.in, which lands in Zoho on a phone that I look at. If you reply, I will read it. If you ask a question, I will probably answer it (sometimes by writing about it in a future issue, with permission and credit). If you tell me an issue did not land, I want to hear that too — I would rather know I missed than keep missing.
A few things that get faster responses:
- A specific question with code attached. I will engage with a screenshot of a stack trace before I will engage with "what do you think about Flutter in 2026?"
- Saying which part of an issue worked or did not — "the snippet shipped" or "the framing was off" both teach me something.
- Keeping it short. A two-sentence reply is great. A six-paragraph essay is also great. A thread of seven follow-ups within an hour, less great — I will catch up on Sunday.
Things I will not be doing in reply: cold-pitch acceptance, sponsorship deals, "quick favor" introductions, or anything that requires a calendar widget. This is a writing channel. If we end up working together, that will happen the slow way through a real project conversation.
What is missing here
You will notice this email does not have a referral program, a paid tier, a Discord, a Slack community, an AI agent, an "exclusive subscriber webinar," or any of the other expansion patterns that newsletter advice in 2026 still recommends. That is on purpose. Adding any of those would change the kind of writing I have to do to feed them, and I want to keep this one small thing small.
If the experiment works for a year and an obvious better shape emerges, I will revisit. Until then it is one writer, one inbox, one email a month. The contract is small enough that I can keep it.
Thanks for being here on the first one. The next issue will land sometime in late May. If it does not show up, that is also part of the contract — silence is allowed, and the unsubscribe link in the footer is one click away if any of this stops being worth the inbox real estate.
— Sinnoor