DEV Community: Fatih İlhan

Building LoopSignal Part 2: The Public Board, Voting, and Prioritization Without the Overhead

Fatih İlhan — Thu, 16 Apr 2026 20:33:55 +0000

In part one, I talked about the very first thing a user does with LoopSignal: submit feedback anonymously, with as little friction as possible.

A quick update since that post: LoopSignal is now listed on GitHub Marketplace. That felt like a good milestone to mention before going deeper into how the product is built.

But a submission going into a void is not a product. It is a contact form.

The next piece was building the public board — the place where approved feedback becomes visible, where users vote, where statuses are tracked, and where a team can see what their users actually want.

This article is about how I built that, and the decisions that shaped it.

What the public board needed to do

Before I wrote any UI, I listed what the board actually had to accomplish.

It needed to:

show only approved posts, not raw submissions
let anonymous users vote without creating an account
let logged-in users have their votes persisted properly
support sorting by votes and by recency
support filtering by status and category
link to a changelog for completed items
work as both a standalone page and eventually an embeddable widget

That is a reasonable surface area for a core feature. Not small, but not bloated either.

The page is a server component

The public board page at /p/[slug] is a React Server Component. That was an easy call.

The page needs data from four places before anything renders:

the project itself (name, settings, categories)
the approved posts, filtered and sorted
the current user's existing votes (if they are logged in)
the comments attached to visible posts

Doing all of that on the server means zero loading states for the initial render. The page arrives fully hydrated. The only client-side work is the vote button itself.

I fetch the project and the auth session in parallel, then the posts and existing votes in parallel after that:

const [{ data: project }, { data: { user } }] = await Promise.all([
  admin.from("projects").select("*").eq("slug", slug).single(),
  supabase.auth.getUser(),
]);

const [{ data: posts }, userVotes] = await Promise.all([
  postsQuery,
  user
    ? admin.from("votes").select("post_id").eq("user_id", user.id)
    : Promise.resolve({ data: [] }),
]);

The result is that on a cold load, the page shows the right content — including whether the user has already voted on something — without any client round-trips.

Moderation is what makes the board clean

This goes back to a decision made in part one.

Every submission starts as pending. A team member reviews it and either approves or rejects it before it appears publicly.

On the board page, the query is always filtered to approved posts only:

let postsQuery = admin
  .from("posts")
  .select("*")
  .eq("project_id", typedProject.id)
  .eq("moderation_status", "approved");

This is a small thing, but it has a big product effect.

A public board without moderation becomes a mess within a week. Duplicate posts, nonsense, spam, test submissions from your own team. Moderation keeps the board worth reading, which keeps users worth engaging.

The moderation queue lives in the dashboard, which I will cover in a later article.

Voting without an account

This was the hardest design problem in the board.

On one hand, I wanted voting to work for logged-in users with proper persistence. On the other hand, I did not want anonymous users to be blocked from participating. Voting is how the board surfaces signal. Blocking anonymous votes would severely reduce the data quality.

The solution I landed on: a localStorage-based voter key for anonymous users, combined with proper user ID tracking for authenticated ones.

When the VoteButton mounts, it reads or generates a UUID from localStorage:

function getVoterKey(): string {
  let key = localStorage.getItem("ls_voter_key");
  if (!key) {
    key = crypto.randomUUID();
    localStorage.setItem("ls_voter_key", key);
  }
  return key;
}

That key gets sent with every vote action. On the server side, the action checks whether there is an authenticated user. If there is, the vote is recorded against the user ID. If not, the voter key is used instead.

This means:

Anonymous users can vote, and their votes persist across page reloads on the same browser
Logged-in users always have their votes properly tracked
The same post cannot be double-voted from the same source

It is not a perfect anti-fraud system. Someone who clears localStorage can vote again. But for the scale LoopSignal is targeting — small product teams, not large open-source projects — it is the right tradeoff. Friction-free participation is worth more than bulletproof deduplication at this stage.

Optimistic updates in the vote button

The VoteButton is a client component. When a user clicks it, the count updates immediately before the server confirms anything.

function handleVote() {
  const newVoted = !hasVoted;
  setHasVoted(newVoted);
  setVoteCount((c) => (newVoted ? c + 1 : Math.max(0, c - 1)));

  startTransition(async () => {
    const result = await voteOnPost(postId, voterKey);
    if (result.error) {
      setHasVoted(!newVoted);
      setVoteCount((c) => (newVoted ? Math.max(0, c - 1) : c + 1));
    }
  });
}

If the server action fails, the state reverts. This gives the button an instant feel while still being correct.

I use useTransition here rather than a loading spinner. The button stays interactive during the transition, which is better for something this small. A spinner on a vote button would feel like overkill.

Sorting and filtering without full-page reloads

The board supports two sort modes — most voted and newest — and two sets of filters: status and category.

I deliberately chose URL-based filtering rather than client-side state.

Every filter and sort option is a link, not a button that updates local state. Clicking "Planned" changes the URL to /p/my-project?status=planned. The server component re-runs with the new params and returns a fresh set of posts.

const { status: statusFilter, sort: sortParam, category: categoryFilter } = await searchParams;

This approach has a few advantages that felt worth the slightly more complex URL building:

Filtered views are bookmarkable and shareable
Browser back/forward works naturally
No hydration mismatches
No client-side data re-fetching logic to maintain

The tradeoff is that filter changes do cause a full navigation. For this kind of read-heavy, low-interaction page, that is perfectly acceptable. Nobody is rapidly toggling filters on a feedback board.

Prioritization without becoming roadmap software

This was a product decision as much as a technical one.

I deliberately kept prioritization simple: vote counts, visible on the board, sortable, filterable by status. That is it.

No scoring formulas. No weighted votes. No segment breakdowns. No "effort vs. impact" matrix.

There are products that do all of that, and they are right for certain teams. But for the kind of user LoopSignal is built for — an indie developer or a small team — that kind of overhead gets in the way rather than helping.

The premise I kept coming back to: if something has 47 votes and the next item has 12, you do not need a scoring algorithm to tell you what users want.

The most useful prioritization tool at this scale is just visibility. See what people asked for, see how many people asked for it, see what you have already committed to. That is enough.

If a team grows to a size where they need weighted scoring and segment filtering, they will probably need a different product. That is fine.

Status labels bridge feedback and roadmap

Each post has a workflow_status that the team controls: open, planned, in progress, completed, closed.

These are visible on the public board as badges on each card.

const statusLabels: Record<string, { label: string; variant: ... }> = {
  open: { label: "Open", variant: "secondary" },
  planned: { label: "Planned", variant: "default" },
  in_progress: { label: "In Progress", variant: "default" },
  completed: { label: "Completed", variant: "outline" },
  closed: { label: "Closed", variant: "outline" },
};

This is the minimum viable roadmap view.

Users can see what is being worked on and what has shipped without the team having to maintain a separate roadmap page. The feedback board is the roadmap, with statuses as the signal.

That status change is also what drives the changelog — but that is for a later article.

Admin comments as public replies

One subtle feature: team members can leave comments on posts, and those comments appear on the public board under the post they belong to.

It is rendered simply:

{(commentsByPost.get(post.id) || []).map((comment) => (
  <div className="flex gap-2 text-sm bg-muted/50 rounded-md p-2 mt-1">
    <MessageSquare className="h-3.5 w-3.5 mt-0.5 text-primary shrink-0" />
    <div>
      <p className="text-foreground">{comment.body}</p>
      <p className="text-xs text-muted-foreground mt-0.5">
        Admin reply · {new Date(comment.created_at).toLocaleDateString()}
      </p>
    </div>
  </div>
))}

This is a small thing that has an outsized effect.

When users see a team member has replied to a request — even just to say "good idea, we will think about it" or "this is planned for next sprint" — it signals that the board is being read by real people.

Empty feedback boards feel abandoned. Boards with admin replies feel alive.

What I learned building this piece

A few things became clear while working on it.

Server components are the right default for data-heavy pages. The board does a lot of reading — project, posts, votes, comments — and doing all of it on the server gives a much better first-render experience than a loading skeleton and three client fetches.

URL-based filtering ages well. Client-side filter state always needs special handling: back button, shareability, initial load from URL. URL-based filtering just works for all of those, without the extra logic.

Anonymous voting is worth the complexity. The voter key approach adds some nuance, but the alternative — blocking anonymous votes — would have killed participation on boards for products that do not require user accounts. The friction cost is too high.

Keeping the board simple keeps it useful. Every time I thought about adding a feature to the board — trending scores, vote breakdowns by country, satisfaction ratings — I asked whether it would make the core use case better or just noisier. Most ideas got cut. The ones that stayed are the ones in this article.

What's next

In the next article, I will go into the GitHub integration: how a team can link an approved feedback post to a GitHub issue with one click, and how issue events automatically close the feedback post and notify users when the issue is resolved.

That is the "loop" in LoopSignal — and it is the part of the product I am most happy with.

If you are building something similar, my takeaway from this part is simple:

Start with the board that shows what users want.

The prioritization and roadmap features only matter after you have real signal coming in.

How I Built Instagram Intelligence Suite for IG Growth

Fatih İlhan — Wed, 15 Apr 2026 19:02:01 +0000

Instagram research usually breaks down in the same three places:

You find profiles, but you still do manual qualification.
You know a brand or influencer is active, but you cannot track story behavior cleanly.
You see high-intent comments under posts and reels, but nobody turns them into structured leads.

That is exactly why I split the workflow into three focused APIs instead of trying to force everything into one oversized scraper:

IGLead for profile qualification
IG_story_snapshot for story activity monitoring
IG_comment_lead for comment-to-lead extraction

All three are built around Apify actors, but the bigger idea is simple: treat Instagram intelligence like a pipeline, not a one-off scrape.

Why I split this into three APIs

A lot of Instagram tools try to do discovery, enrichment, monitoring, and lead scoring in one place. That sounds convenient until the inputs, auth requirements, and output formats start fighting each other.

I wanted each API to answer one clean question:

IGLead: Is this profile worth contacting?
IG_story_snapshot: Is this profile active on stories right now?
IG_comment_lead: Which commenters look like real demand?

That separation makes the stack easier to maintain, easier to schedule, and easier to plug into downstream automations.

1. IGLead: qualifying influencer and creator profiles before outreach

IGLead starts with a list of Instagram usernames or profile URLs and turns them into scored outreach candidates.

Instead of just scraping follower counts, it combines multiple signals:

follower count
recent post engagement
engagement rate
business email detection from public bio text
niche keyword matching
verification status
a final lead score and recommendation

One thing I especially like in this API is that the scoring is not flat. Engagement expectations change depending on account size. A micro creator should not be evaluated like a mega influencer, so the actor adjusts its thresholds by tier.

It also uses multiple extraction paths for reliability:

Instagram web profile API
feed endpoints when timeline media is incomplete
HTML parsing fallbacks
meta tag parsing for follower and post counts

That matters because Instagram is rarely stable enough for a single-method scraper.

Example `IGLead` input

{
  "profiles": ["therock", "cristiano", "https://www.instagram.com/kyliejenner/"],
  "sessionId": "YOUR_SESSION_ID",
  "minFollowers": 100000,
  "minEngagementRate": 1.0,
  "requireBusinessEmail": false,
  "nicheKeywords": ["fitness", "health", "wellness"],
  "maxProfilesPerRun": 50,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

What comes back

For each profile, IGLead can return:

normalized profile data
recent post stats
average and median engagement metrics
extracted business email if it is publicly visible in the bio
niche match score
leadScore
recommendation such as contact, review, or skip

For outreach teams, that means you can stop treating every Instagram profile as equal. You can prioritize the ones that actually fit your campaign and have the engagement to justify the spend.

2. IG_story_snapshot: monitoring story activity without owning the account

Stories are one of the hardest parts of Instagram to operationalize because they are temporary, fast-moving, and usually checked manually.

IG_story_snapshot is built to answer a very specific operational question:

Does this public profile have an active story right now, and what does that story set look like?

It tracks:

whether a profile currently has an active story
how many story frames are live
image vs video composition
oldest and newest story timestamps
hours since the story sequence started
hours left until expiry
optional profile context such as follower count

This is useful for:

competitor monitoring
campaign verification
event coverage tracking
brand activity benchmarking

What I like most here is that it avoids trying to do too much. It does not pretend to give story view counts, and it does not download story content. It focuses on presence and metadata, which is the part most teams actually need for monitoring.

Example `IG_story_snapshot` input

{
  "profiles": ["nike", "adidas", "@puma"],
  "sessionId": "YOUR_SESSION_ID",
  "includeProfileContext": true,
  "maxProfilesPerRun": 50,
  "maxRequestsPerMinute": 15,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}

What comes back

The output is centered around a few operational fields:

active_story
story_count
story_frames
story_metadata
story_age_hours
hours_left_until_expiry

That makes the API especially useful for scheduled runs. If you execute it every hour, you can build a clean timeline of who is posting stories, how often they post, and whether they lean more toward video or image content.

3. IG_comment_lead: turning Instagram comments into lead intelligence

IG_comment_lead is the most directly sales-oriented API in the stack.

The idea is straightforward: people reveal intent in comments all the time. They ask about price, shipping, details, availability, or how to order. Most teams read those comments manually, if they read them at all.

This API takes Instagram post or reel URLs, fetches comments, and scores commenters based on lead relevance.

The pipeline includes:

input validation for post and reel URLs
authenticated scraping with sessionId
fallback comment extraction strategies
keyword-based intent scoring
lightweight sentiment scoring
spam checks
deduplication by username
early stopping once the target lead count is reached
a final analytics summary for the whole run

I also like that this API is optimized for cost control. You can cap comments per post, define a minimum lead score, and stop the run as soon as enough leads are found.

Example `IG_comment_lead` input

{
  "postUrls": [
    "https://www.instagram.com/p/C3xYz1234Ab/",
    "https://www.instagram.com/reel/C3xYz5678Cd/"
  ],
  "sessionId": "YOUR_SESSION_ID",
  "cookie": "sessionid=...; csrftoken=...; ds_user_id=...;",
  "maxCommentsPerPost": 500,
  "targetLeads": 30,
  "minLeadScore": 0.6,
  "debugComments": false
}

What makes this one interesting

The comment fetch flow does not rely on a single endpoint. It tries multiple strategies:

GraphQL queries
shortcode-based REST endpoints
mobile-style REST endpoints

That gives it a better chance of surviving endpoint instability.

On top of extraction, it enriches leads with:

buyer_intent_score
engagement_score
likely customer flag
extracted keywords
inferred niche
inferred geography

At the end of a run, it also pushes an analytics summary with:

total comments processed
total leads found
lead rate
top commenters
intent distribution
sentiment distribution
top keywords
per-post breakdown

That means the output is useful for both direct lead capture and campaign analysis.

How the three APIs work together

The fun part is not each API in isolation. It is the workflow they create together.

A practical sequence looks like this:

Use IGLead to qualify creators, influencers, or niche accounts before outreach.
Use IG_story_snapshot to monitor who is actively posting stories right now.
Use IG_comment_lead on posts and reels in your niche to surface warm demand from commenters.

That gives you three different layers of Instagram intelligence:

profile quality
current activity
audience intent

In other words, you can answer:

Who should I contact?
Who is active right now?
Who is already asking buying questions?

Implementation notes

All three projects are built around the same practical philosophy:

use Apify actors for deployment and scheduling
use Crawlee for request orchestration
use Playwright when browser context is needed
keep concurrency controlled to reduce blocks
use fallback strategies instead of trusting one endpoint
support session cookies when Instagram requires authentication
preserve debug artifacts when extraction fails

For IGLead, that means debug HTML and screenshots when profile parsing breaks.

For IG_story_snapshot, that means API-first story detection with a visual fallback for story presence.

For IG_comment_lead, that means endpoint fallback plus a summary record at the end so a run is not just raw data, but something closer to decision-ready output.

What I would improve next

If I keep iterating on this stack, these are the next areas I would push:

cross-actor orchestration so leads can move automatically from one API to the next
historical storage for story activity trends over weeks instead of single snapshots
richer commenter enrichment for repeat engagement across multiple posts
better dashboarding on top of the analytics summary

The core scraping part is useful, but the real leverage comes from building a repeatable operating system around it.

Final thoughts

The biggest lesson from building IGLead, IG_story_snapshot, and IG_comment_lead is that Instagram automation becomes much more useful when you stop thinking in terms of "scrape a page" and start thinking in terms of "answer a business question."

Each API here is narrow on purpose:

IGLead answers qualification
IG_story_snapshot answers activity
IG_comment_lead answers intent

Put together, they form a lightweight Instagram intelligence stack for outreach, competitor research, and lead generation.

If you are building in this space, I would strongly recommend resisting the urge to turn everything into one monolith. Small, composable APIs are easier to trust, easier to debug, and much easier to turn into real workflows.

You can find all of my APIs here: https://apify.com/store/categories?search=seralifatih

Building LoopSignal Part 1: Anonymous Feedback Submission in Next.js 15

Fatih İlhan — Sat, 11 Apr 2026 18:06:57 +0000

When I started building LoopSignal, I did not begin with GitHub sync, changelogs, or billing.

I started with the very first thing a user would do: submit feedback.

That sounds small, but for a product like LoopSignal, it is the foundation for everything else. If submitting feedback feels annoying, too formal, or too slow, the rest of the product does not matter. No votes, no roadmap, no changelog, no loop to close.

So this first article in the series is about the first core problem I wanted to solve:

How do you let users submit useful product feedback with as little friction as possible, without opening the door to spam and chaos?

The problem with most feedback forms

A lot of feedback tools make the same mistake early.

They treat feedback submission like a mini onboarding flow.

Create an account.

Verify your email.

Fill out a long form.

Pick a category.

Pick a board.

Confirm your submission.

At that point, most users are already gone.

That might work if your users are deeply invested power users, but for most SaaS products, feedback happens in small moments:

someone hits a rough edge
someone wants one missing feature
someone notices a bug
someone has an idea while using the app

If you add too much friction in that moment, you lose the feedback entirely.

For LoopSignal, I wanted the opposite approach:

no account required
optional email for updates
short, low-friction form
moderation before public visibility
enough checks to prevent obvious abuse

That became the starting point.

What the submission flow needed to do

Before I wrote any UI, I made a short list of requirements.

A submission should:

work from a public board
work from an embedded widget
allow anonymous users
optionally collect an email for status updates
validate title and description
rate-limit abusive traffic
detect obvious spam
store the post in a pending state for moderation
subscribe the submitter for future notifications

That is not a huge system, but it is enough to turn a simple form into a real product feature.

Why anonymous submission mattered

This was one of the earliest product decisions I felt strongly about.

If LoopSignal is meant for indie developers and small teams, it cannot assume their end users want to create accounts just to suggest something.

A user should be able to open a public board, type:

"Would love dark mode scheduling"

and hit submit.

That is it.

If they want updates, they can leave an email. If they do not, the feedback should still count.

That one decision shapes a lot of the implementation:

you cannot rely on user auth for identity
you need basic anti-spam protections
you need moderation
you need a clean public workflow for anonymous posts

But I still think it is the right tradeoff. More friction might make the system cleaner internally, but it would also make the product worse at collecting signal.

The data model

At the database level, the first important table was posts.

I needed each feedback item to track both moderation state and product workflow state, because those are different things.

A post might be:

pending moderation
approved and open
planned
in progress
completed
closed
rejected before ever becoming public

That led to fields like these:

type Post = {
  id: string;
  project_id: string;
  title: string;
  description: string | null;
  category: string | null;
  email: string | null;
  ip: string | null;
  spam_score: number;
  moderation_status: "pending" | "approved" | "rejected";
  workflow_status: "open" | "planned" | "in_progress" | "completed" | "closed";
  created_at: string;
};

The important part here is that moderation and workflow are separate.

That keeps the public board clean and makes the later product flow much easier to reason about.

Why I used a server action for submission

LoopSignal is built with Next.js 15, and for this kind of mutation, server actions felt like a good fit.

I did not need a big REST surface just to support one form. I needed a secure write path with access to:

request metadata
auth context if available
headers and IP information
database access
cache revalidation

That is exactly the kind of job server actions are good at.

The flow looked like this:

Validate the incoming form data
Read the client IP
Check rate limits
Run spam scoring
Insert the post as pending
Subscribe the email if one exists
Return a simple success or error response

The core of it looked like this:

const spam = checkSpam({ title, description, email, ip });

if (spam.isSpam) {
  await logSpam(ip, "spam_detected", spam.signals, spam.score, {
    title,
    description,
    email,
  });

  return { error: "Your submission was flagged." };
}

const { data: newPost } = await admin
  .from("posts")
  .insert({
    project_id: projectId,
    title,
    description,
    category,
    email: email || user?.email || null,
    ip,
    spam_score: spam.score,
    moderation_status: "pending",
    workflow_status: "open",
  })
  .select("id")
  .single();

There is nothing especially fancy here, and that is part of the point.

A lot of good product code is just careful code, not clever code.

Moderation was not optional

The moment you allow anonymous submissions, moderation stops being a nice-to-have.

Even if your product is small, public forms eventually attract junk:

spam links
repeated nonsense
promotional messages
low-effort duplicate posts

I did not want LoopSignal to become one of those "technically open, practically unusable" public boards.

So every new submission starts as pending.

That gives teams a lightweight review layer before something appears publicly. It also lets the product stay open to anonymous participation without making the board feel messy.

This ended up being one of the most important quality-of-life decisions in the whole product.

Open submission works much better when moderation is built in from day one.

Anti-spam without overengineering it

I did not want to begin with a complex third-party moderation stack.

Instead, I started with a simple scoring approach.

Things that add spam weight include:

all-caps titles
too many links
repeated characters
suspicious email patterns
known spam phrases

That is enough to catch a surprising amount of bad input.

The goal here is not perfect classification. The goal is to block obvious junk while keeping the system fast and lightweight.

That is a pattern I keep coming back to in product work:

Start with the simplest version that meaningfully reduces pain.

If it turns out to be insufficient, then you have real usage data to justify something more advanced.

Optional email was better than required auth

This was another small decision that had a big product effect.

I still wanted users to be able to hear back when something changed. That is part of the whole "close the loop" idea behind LoopSignal.

But I did not want updates to require registration.

So the form allows an optional email field.

If a user includes it, they can get notified when the request is approved, planned, completed, or replied to. If they leave it blank, the feedback still gets submitted.

That gave me a much better balance:

low friction for submitting
enough contact info for follow-up when users want it
no forced signup just to leave one idea

In practice, that feels much more aligned with how users actually behave.

One subtle thing this unlocked later

Building submission first clarified the rest of the product.

Once you have a clean, low-friction way to collect feedback, the next pieces become much more obvious:

approved posts can appear on the public board
users can vote on them
teams can change statuses
approved requests can create GitHub issues
completed items can feed the changelog

That is why I think the submission flow was the real starting point of LoopSignal, even if it is not the flashiest feature.

It defined the shape of the whole system.

What I learned from building this piece

A few things became very clear while working on it.

First, friction matters more than formality.

A clean, lightweight submission experience will produce more useful feedback than a "proper" workflow with too many steps.

Second, anonymous does not have to mean uncontrolled.

If you combine rate limits, spam scoring, and moderation, you can keep the door open without letting the system turn into noise.

Third, optional identity is often better than mandatory identity.

Sometimes the best way to get signal is to make participation easy, then let users opt into deeper engagement.

And finally, building the smallest meaningful loop is a better starting point than trying to design the entire platform up front.

In LoopSignal's case, that loop started with one question:

How do I make it as easy as possible for someone to tell a product team what they want?

Everything else came after that.

What's next

In the next article, I'll go deeper into the public board itself: how approved feedback becomes visible, how voting works, and how I approached prioritization without turning the product into heavy roadmap software.

If you are building something similar, my biggest takeaway from this part is simple:

Do not start by designing the perfect feedback system.

Start by removing everything that makes feedback harder to send.

Why Every AI Developer Should Try the `caveman` Repo (Even If It Looks Like a Joke)

Fatih İlhan — Fri, 10 Apr 2026 11:23:25 +0000

If you work with AI coding assistants long enough, you start noticing something annoying.

Your AI tools are extremely smart… but extremely verbose.

You ask a simple question and get:

“Sure! I’d be happy to help with that. The issue you’re experiencing is likely caused by…”

And suddenly you're paying for three paragraphs of politeness before the actual answer.

That’s where a tiny open-source repo called caveman comes in.

And surprisingly, it might be one of the most practical AI workflow hacks of 2026.

What Is Caveman?

caveman is a Claude Code / AI-agent skill created by Julius Brussee that forces an AI to communicate in ultra-compressed language while keeping the technical meaning intact.

The idea is simple:

Why use many token when few token do trick.

Instead of:

“The reason your React component is re-rendering is likely because you're creating a new object reference each render cycle…”

Caveman produces something like:

New object ref each render.
Inline object prop = new ref = re-render.
Wrap in useMemo.

Same solution.

75% fewer tokens.

The Real Problem: AI Is Too Polite

Most LLM responses contain a lot of unnecessary language:

Politeness (“Sure! Happy to help!”)
Hedging (“It might be worth considering…”)
Conversational glue
Articles and filler words

Individually they don't matter.

But across thousands of agent calls, they become expensive.

Token consumption becomes the hidden tax of AI workflows.

Caveman attacks exactly that.

It removes:

Articles (a, an, the)
Pleasantries
Filler words
Hedging language

And keeps only:

Technical terms
Code blocks
Actual instructions

What Benefits Do You Actually Get?

1. Massive Token Savings

Caveman claims ~65–75% reduction in output tokens across typical programming tasks.

Example results from real prompts:

Task	Token Reduction
React debugging	~87%
Auth middleware bug	~83%
PostgreSQL race condition	~81%

That means:

cheaper AI usage
longer agent sessions
less context window pressure

2. Faster Responses

Less output means less generation time.

If you use AI in tools like:

Claude Code
Cursor
Codex
agent pipelines

you’ll feel the difference immediately.

Large outputs slow everything down.

Short outputs keep the loop tight.

3. Higher Signal-to-Noise Ratio

Ironically, brevity often improves clarity.

Instead of:

"The issue you're experiencing is likely caused by…"

You get:

Bug in auth middleware.
Token expiry check use < not <=.
Fix:

This style works incredibly well for:

debugging
code review
architecture hints
agent communication

4. Surprisingly Easy to Install

One command:

npx skills add JuliusBrussee/caveman

Then trigger it with:

/caveman

And your AI switches modes instantly.

Why This Repo Went Viral

The reason cavemanexploded on Hacker News and GitHub is simple.

It exposes a painful truth:

Most AI responses waste tokens.

Developers already felt it.
Caveman just turned the feeling into a tool.

The project also shows something interesting:

Prompt engineering can sometimes beat architecture changes.

No new model.

No compression algorithm.

Just better constraints on output style.

One Important Caveat

Caveman does not reduce thinking tokens.

It only compresses the visible output.

So:

reasoning cost stays the same
but response tokens shrink dramatically For most agent workflows, that's still a big win.

When Caveman Is Actually Useful

Best use cases:

AI coding assistants
agent pipelines
automated code review
debugging loops
CI AI tools

Worst use cases:

tutorials
documentation
learning explanations Basically:

Use caveman when you want answers, not essays.

Final Thoughts

cavemanlooks like a joke.

But it's actually a great example of developer-driven AI tooling.

Tiny repo.
Simple idea.
Huge practical impact.

Sometimes the best optimization isn't a new model.

It's just telling the model:

Speak less.

If you're experimenting with AI coding workflows, it's definitely worth trying.

Your token budget might thank you.

I Built a Trading Signal Engine That Reads Congressional Insider Trades — Here's the Architecture

Fatih İlhan — Thu, 09 Apr 2026 06:59:29 +0000

Congressional members beat the market by 12% on average. I built a system to find out why — in real time.

There's a dataset hiding in plain sight. Every time a U.S. senator or congressman buys stock, they're legally required to disclose it within 45 days. Every time a corporate CEO buys their own company's shares, that Form 4 hits the SEC within 2 business days.

Most people scroll past these filings. I built a machine to read all of them, filter out the noise, and surface only the trades worth paying attention to.

This is the architecture behind Insider Signal Engine — a personal trading signal tool I built in a few weeks using Next.js, Supabase, and Cloudflare Workers.

The Problem: Raw Insider Data Is Mostly Noise

The data is public. The problem is the signal-to-noise ratio.

In any given week, you might see 400+ congressional trade disclosures. But most of them are:

Sales (informationless — could be divorce, taxes, anything)
Filed 38 days after the trade (already priced in)
Tiny amounts ($1K–$15K, basically rounding errors)
From members with no relevant committee oversight

Running a filter stack on that data is the whole game.

Stack

Layer	Choice	Why
Framework	Next.js 14 App Router	Dashboard + API routes in one project
Database	Supabase (Postgres)	RLS-ready for multi-tenant SaaS later
Hosting	Cloudflare Pages	Edge performance, generous free tier
Cron	Cloudflare Workers (scheduled)	Runs the ingestion pipeline every 4 hours
Primary data	Quiver Quant API ($10/mo)	Congressional + insider trades, clean REST API
Secondary data	Financial Modeling Prep (free tier)	Earnings calendar, corporate Form 4

The ingestion pipeline runs as a Cloudflare Worker on a cron schedule, hits an internal protected API route, and writes to Supabase. The Next.js dashboard reads from Supabase and renders signals sorted by score.

Architecture

┌─────────────────────────────────────────────┐
│         CLOUDFLARE WORKER (every 4h)         │
│                                              │
│  1. Fetch congress trades from Quiver Quant  │
│  2. Fetch corporate insider trades (FMP)     │
│  3. Normalize into unified RawTrade schema   │
│  4. Run 7-filter stack                       │
│  5. Score survivors (0-100)                  │
│  6. Upsert into Supabase signals table       │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
             Supabase (Postgres)
             ├── raw_trades  (append-only log)
             ├── signals     (filtered + scored)
             └── politicians (track record)
                       │
                       ▼
          Next.js Dashboard (App Router)
          /              → Signal feed
          /politicians   → Leaderboard by hit rate
          /ticker/[sym]  → Per-stock activity
          /backtest      → Historical performance

The 7-Filter Stack

This is the core of the engine. Every trade must pass all 7 filters to become a signal. Filters are pure functions — simple to test, easy to tune.

type TradeFilter = (trade: RawTrade) => boolean;

Filter 1: Purchases Only

const filterPurchaseOnly: TradeFilter = (trade) =>
  trade.trade_type === 'purchase';

Sales have too many non-informative motivations — taxes, diversification, estate planning. Buys are different. Nobody buys their own stock for the wrong reasons.

(Exception: unusually large sales >$500K go to a separate "bearish watchlist" — not implemented yet.)

Filter 2: Filing Delay ≤ 7 Days

const filterFilingDelay: TradeFilter = (trade) => {
  const delay = differenceInDays(
    parseISO(trade.filing_date),
    parseISO(trade.trade_date)
  );
  return delay <= 7;
};

Congress has 45 days to disclose. Most of them use every day of it. This filter rejects ~80% of congressional trades by design.

The fast-filers are a self-selecting group. When a senator buys $500K of defense stock and files the next day, that's a different animal from someone who files at day 44.

Filter 3: Minimum Size ≥ $50K

const filterMinSize: TradeFilter = (trade) => {
  const amount = trade.amount_high ?? trade.amount_low ?? 0;
  return amount >= 50_000;
};

Congress reports in ranges — $1K–$15K, $15K–$50K, $100K–$250K. We use the upper bound. The $50K floor eliminates noise buys and auto-purchase plans.

Filter 4: Relevance — Committee Match or C-Suite

const COMMITTEE_SECTOR_MAP: Record<string, string[]> = {
  'Armed Services': ['defense', 'aerospace'],
  'Energy and Commerce': ['energy', 'utilities', 'healthcare'],
  'Finance': ['banks', 'fintech', 'crypto'],
  'Intelligence': ['defense', 'cybersecurity', 'tech'],
  // ...
};

const C_SUITE_TITLES = ['CEO', 'CFO', 'COO', 'CTO', 'President', 'Chairman'];

A senator on the Senate Intelligence Committee buying a cybersecurity stock is a different signal than a backbencher doing the same. A CEO buying their own stock means something. A Director buying theirs means less.

Filter 5: Cluster Detection

Not a per-trade filter — a post-filter enrichment. After filters 1-4, we group surviving trades by ticker in a 30-day sliding window:

function detectClusters(
  filteredTrades: RawTrade[],
  windowDays: number = 30
): ClusterResult[] {
  const byTicker = groupBy(filteredTrades, 'ticker');

  for (const [ticker, trades] of Object.entries(byTicker)) {
    if (trades.length < 2) continue;
    // sliding window: find groups of 2+ trades within windowDays
  }
}

When 3 different insiders buy the same ticker in the same month, that's a cluster. Clusters get heavily rewarded in the scoring model.

Filter 6: No Earnings Gamble (Async)

const filterNoEarningsGamble = async (trade: RawTrade): Promise<boolean> => {
  const earningsDate = await getNextEarningsDate(trade.ticker); // FMP API
  if (!earningsDate) return true;

  const diffDays = differenceInDays(
    parseISO(earningsDate),
    parseISO(trade.trade_date)
  );

  return diffDays < 0 || diffDays > 5;
};

Insider buys 3 days before an earnings beat look brilliant in hindsight. They're also binary event gambling. This filter runs only on the survivors from 1-4, minimizing API calls to FMP's free tier (250 req/day limit).

Filter 7: Technical Check (Stub — Phase 2)

Placeholder for a 200-day SMA guardrail: reject trades where the stock is more than 20% below its long-term average. Falling knives are falling knives, even with insider buying.

The Scoring Model (0–100)

Every trade that survives the filters gets a score. The score is a sum of 6 components:

interface ScoreBreakdown {
  size_score: number;         // 0-20
  delay_score: number;        // 0-15
  cluster_score: number;      // 0-25  ← most impactful
  filer_track_record: number; // 0-20
  relevance_score: number;    // 0-10
  recency_score: number;      // 0-10
}

The thresholds:

// SIZE (0-20)
if (amount >= 500_000)      size_score = 20;
else if (amount >= 250_000) size_score = 16;
else if (amount >= 100_000) size_score = 12;
else if (amount >= 50_000)  size_score = 8;

// FILING DELAY (0-15)
if (delayDays <= 1)      delay_score = 15;
else if (delayDays <= 3) delay_score = 12;
else if (delayDays <= 5) delay_score = 8;
else if (delayDays <= 7) delay_score = 4;

// CLUSTER (0-25) — the big one
if (cluster_strength >= 4)      cluster_score = 25;
else if (cluster_strength >= 3) cluster_score = 20;
else if (cluster_strength >= 2) cluster_score = 12;

// TRACK RECORD (0-20) — needs 10+ historical trades to activate
if (hit_rate >= 70) filer_track_record = 20;
else if (hit_rate >= 60) filer_track_record = 15;
else if (hit_rate >= 50) filer_track_record = 10;

The score is stored alongside the full breakdown as a JSONB column in Postgres:

CREATE TABLE signals (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  ticker TEXT NOT NULL,
  filer_name TEXT NOT NULL,
  filer_type TEXT NOT NULL,         -- 'congress' | 'corporate_insider'
  score INT CHECK (score BETWEEN 0 AND 100),
  score_breakdown JSONB NOT NULL,   -- { size_score, delay_score, ... }
  filters_passed TEXT[] NOT NULL,
  cluster_id UUID,
  filing_delay_days INT NOT NULL,
  -- ...
);

This means I can always explain why a trade scored the way it did — not just the final number.

Data Model: Three Core Tables

raw_trades — append-only ingest log. Every trade from every source lands here first, before filtering. Has a UNIQUE(source, source_id) constraint — upsert only, never blind insert.

signals — filtered and scored trades only. References raw_trades via FK. This is what the dashboard reads.

politicians — filer lookup with a computed hit_rate column (winning trades / total trades × 100, calculated in Postgres):

hit_rate NUMERIC GENERATED ALWAYS AS (
  CASE WHEN total_trades > 0
  THEN (winning_trades::NUMERIC / total_trades) * 100
  ELSE 0 END
) STORED

The Ingestion Pipeline

The whole flow lives in a single orchestrator function:

async function runIngestionPipeline() {
  // 1. Fetch
  const [congressTrades, insiderTrades, fmpTrades] = await Promise.all([
    quiverClient.fetchCongressTrades(7),
    quiverClient.fetchInsiderTrades(7),
    fmpClient.fetchInsiderTrades(7),
  ]);

  const rawTrades = [...congressTrades, ...insiderTrades, ...fmpTrades];

  // 2. Dedup + store
  await upsertRawTrades(rawTrades); // UNIQUE constraint handles dedup

  // 3. Filter (sync first, async only on survivors)
  const { passed, clusters, rejected } = await runFilterStack(rawTrades);

  // 4. Score
  const signals = await Promise.all(
    passed.map(trade => scoreWithContext(trade, clusters))
  );

  // 5. Store
  await upsertSignals(signals);

  // 6. Expire old signals
  await markStaleSignals(30); // is_active = false after 30 days

  console.log(`Pipeline: ${rawTrades.length} ingested → ${passed.length} signals`);
}

The cron endpoint is protected by a secret header — no auth library needed:

// /src/app/api/cron/route.ts
export async function GET(request: Request) {
  const secret = request.headers.get('x-cron-secret');
  if (secret !== process.env.CRON_SECRET) {
    return new Response('Unauthorized', { status: 401 });
  }

  await runIngestionPipeline();
  return new Response('OK');
}

What Makes This Different From Just Using Quiver

Quiver shows you raw data. Capitol Trades shows you raw data. Unusual Whales shows you raw data — with prettier charts.

Nobody gives you a confidence score. Nobody tells you "this specific combination of factors — a cluster of 3 insiders, fast filing, large size, from a senator on the Finance Committee — has historically been worth paying attention to."

The filter stack + scoring model is the IP. The data is commodity.

Phase Roadmap

Phase 1 (done): Personal tool. Use it for 4 weeks. Track accuracy manually.

Phase 2: Backtest engine — calculate 7/30/90-day returns for every historical signal. This turns the hit rate columns from placeholders into real data. Add Telegram alerts for score ≥ 70.

Phase 3: Multi-tenant SaaS via Supabase Auth + RLS. Pricing: free tier (3 signals/day, delayed) → Pro at $15/mo (real-time feed, full history, alerts, backtest). Break-even is literally 1 paying user — infrastructure cost at this scale is basically $10/mo for the Quiver API.

Phase 4: AI-generated trade thesis per signal. Cross-reference with FDA calendar, earnings, legislation schedule. The data is already there — it just needs context.

Competitive Moat

The barrier here isn't data access — it's the model. Quiver, Unusual Whales, and Capitol Trades all show you the same filings. The moat is:

The scoring model accumulates historical calibration over time (the hit_rate column)
Cluster detection catches coordinated buying that raw feeds miss
The filter stack eliminates noise that makes other tools feel overwhelming

Congressional trading platforms all have the same problem: too much signal, not enough filtering. Most users end up ignoring them after a few weeks because they don't know which trades to act on. A score from 0-100 solves that UX problem.

Key Technical Decisions

Why Quiver Quant over scraping? Capitol Trades has no API. You could scrape it with Apify, but Quiver gives you normalized data plus corporate insider trades, lobbying data, and WSB sentiment in one REST API. $10/mo vs. scraper maintenance is an easy call.

Why 7-day filing delay and not 45? This deliberately rejects ~80% of congressional trades. The fast-filers are a statistically distinct group. If I'm wrong about this hypothesis, the backtest data will tell me — and I can loosen the filter.

Why Cloudflare Workers for cron? Free tier covers 100K requests/day and unlimited scheduled workers. No Lambda cold starts. The entire infrastructure cost at personal-use scale is $10/mo (Quiver API only).

Why Supabase over plain Postgres? Row-Level Security means multi-tenant is a schema migration away, not an architectural rewrite. The free tier covers ~50K signals, which is years of personal use.

What's Next

Right now this is a personal tool — I use it for my own trading and I'm not ready to open it up yet. I want to run it for a few months, validate the scoring model against real returns, and see if the signals actually hold up before putting it in front of anyone else.

If the backtest data looks good, this becomes a product. The infrastructure is already designed for it — Supabase RLS for multi-tenancy, Cloudflare Pages for edge delivery, Paddle for payments. The jump from personal tool to SaaS is mostly a pricing page and an auth flow.

If you're building something similar or have thoughts on the filter logic, I'd love to hear it in the comments.

Built with Next.js 14, TypeScript strict mode, Supabase, Cloudflare Pages + Workers, and Quiver Quant API. Stack is fully open — the IP is in the filtering logic, not the framework choices.

Not financial advice. Congressional disclosure data is public record.

Building OneRule: A Technical Deep Dive into an Offline Password Manager with Flutter, SQLCipher, and AES-GCM

Fatih İlhan — Wed, 08 Apr 2026 07:19:31 +0000

Password managers often get discussed at product level: sync, UX, pricing, recovery, browser extensions.

What interested me more in OneRule was lower in stack:

what "offline-first" actually means in implementation
how local key derivation is handled
where encryption boundaries sit
how Flutter and native Android divide responsibility

OneRule is an open-source Android password manager built with Flutter. It does not require an account or backend for core vault operations. The interesting part is not only that it works offline, but that the architecture is intentionally shaped around that constraint.

This post is a technical walkthrough of current implementation: storage model, key flow, backup format, panic mode behavior, and Android Autofill boundary.

Architectural Shape

At code level, OneRule follows a fairly direct layered structure:

Flutter UI for screens, forms, and interaction flows
Provider-based state for app-level reactive data
service and facade classes for storage, crypto, backup, auth, clipboard, and platform integration
native Android code where platform APIs are necessary, especially Autofill

In practical terms, the flow looks like this:

UI/screens
  -> Provider state
    -> service/facade layer
      -> SQLCipher / secure storage / crypto / platform channels

This is not an especially exotic architecture, but it fits security-sensitive mobile software well. UI code stays mostly unaware of encryption details. Providers coordinate visible app state. Services own the mechanics of vault initialization, field encryption, backup creation, and unlock behavior.

For a Flutter app, that separation matters because it reduces chances that sensitive logic leaks into widget code and becomes harder to reason about.

The startup path is also explicit about local protections. On launch, the app initializes error handling and reminder services, then enables screen-capture protections before rendering UI:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await LocalLogService.instance.initializeGlobalErrorHandlers();
  await BackupReminderService.instance.initialize();

  if (Platform.isAndroid || Platform.isIOS) {
    await ScreenProtector.preventScreenshotOn();
    await ScreenProtector.protectDataLeakageOn();
    await ScreenProtector.protectDataLeakageWithBlur();
  }

  runApp(/* providers + app */);
}

That is small, but it shows something important about OneRule: operational security controls are part of app bootstrap, not optional polish added later.

Data-at-Rest Model

The vault is not stored as plaintext records in local SQLite.

OneRule uses SQLCipher-backed SQLite as the primary vault store. The database file is encrypted at rest, and the SQLCipher password is derived from the active in-memory session key.

But the design does not stop there.

The password field is also encrypted again at application level using AES-256-GCM. So the current storage model is effectively:

encrypted database file via SQLCipher
encrypted sensitive field payloads inside that database

That second layer is important. It means the most sensitive credential field is stored and serialized as an authenticated encrypted envelope, not only as a row protected by database-level encryption. When the Flutter app needs to render or analyze entries, it decrypts that field at read time.

The current field payload format is versioned and structured like this:

or1:v2:gcm:<nonce_b64url>:<cipherText_b64url>:<tag_b64url>

Using a versioned envelope instead of opaque bytes makes future migrations much easier. It also gives the app a clean way to distinguish between:

current AES-GCM records
legacy AES-CBC records
pre-envelope data from older versions

That matters because OneRule includes migration logic and does not assume the vault will always start in latest format.

For backups, the code takes the same approach: explicit envelope, explicit metadata, explicit version.

Key Derivation and Session Model

The master PIN is not used directly as an encryption key.

Instead, OneRule derives key material with PBKDF2-HMAC-SHA256. Current implementation uses:

100,000 iterations for interactive PIN unlock/session derivation
256-bit output
16-byte random salts

Backup encryption uses a separate derivation profile:

PBKDF2-HMAC-SHA256
200,000 iterations
256-bit output
16-byte random salt embedded in backup payload

That separation is a good design choice. Unlock flows need acceptable latency on-device. Backup export and import can afford a higher work factor because they are less frequent and less latency-sensitive.

The session model is also worth calling out:

the active vault session key is kept in memory
SQLCipher password is derived from that key
secure storage holds salts, verifiers, and biometric-restorable material
session key is cleared on logout and lock paths

So the app has a fairly explicit distinction between:

persistent verification or recovery metadata
active decrypted session state

That is small but important. A lot of local-first security design is really state-lifecycle design.

Backup derivation path is straightforward and readable in code:

Future<SecretKey> _deriveKey(String passphrase, List<int> salt) async {
  final pbkdf2 = Pbkdf2(
    macAlgorithm: Hmac.sha256(),
    iterations: _pbkdf2Iterations,
    bits: 256,
  );
  return pbkdf2.deriveKey(
    secretKey: SecretKey(utf8.encode(passphrase)),
    nonce: salt,
  );
}

Then the payload is encrypted with AES-GCM using fresh salt and nonce:

final salt = _randomBytes(16);
final nonce = _randomBytes(12);
final key = await _deriveKey(passphrase, salt);

final secretBox = await _gcm.encrypt(
  utf8.encode(plaintext),
  secretKey: key,
  nonce: nonce,
);

Why SQLCipher Plus Field-Level AES-GCM?

A reasonable question is: if SQLCipher already encrypts database file at rest, why encrypt the password field again?

The answer is separation of concerns.

SQLCipher protects the database as a container. Field-level AES-GCM protects the most sensitive payloads as application-managed cryptographic objects with explicit integrity tags and versioned envelopes.

That gives OneRule a few advantages:

clean migration path from old formats to new ones
explicit tamper detection at field level
easier reuse of encrypted credential payloads outside normal Flutter list rendering
tighter control over what can be serialized or handed to native layers

The Android Autofill integration benefits directly from this. More on that later.

Vault Migration Strategy

OneRule still contains migration support for older storage models.

There are two migration stories in current codebase:

1. Legacy vault backend migration

Older vault data could exist in Hive-based storage. Current architecture uses SQLCipher, and the app includes a one-time migration reader that imports legacy records into encrypted SQLite, then removes old box data and marks migration complete.

2. Legacy cipher format migration

Password payloads and backup payloads have moved from older layouts into AES-GCM-based envelopes.

For vault records, the app can still read:

legacy CBC envelope format
older marker-based GCM payloads
older plaintext-style legacy values

On unlock, rows are scanned and migrated into current or1:v2:gcm format. Migration is designed to be non-lossy:

read legacy payload
decrypt or parse
re-encrypt in latest format
persist migrated value

If crypto validation fails, migration hard-fails rather than overwriting questionable data.

That is exactly what you want in security migration code. Silent best-effort conversion is dangerous when integrity matters.

Backup Format and Cryptographic Container

Offline-first apps still need a portability story. Otherwise "no sync" quickly turns into "single-device risk."

OneRule handles that with encrypted backup export and import. Current export format is a JSON-based .enc container with schema version v: 3.

The backup pipeline looks like this:

collect vault records
serialize plaintext JSON
derive encryption key from backup passphrase using PBKDF2-HMAC-SHA256
encrypt with AES-256-GCM using random nonce
emit structured JSON container with metadata

The container includes:

KDF metadata
cipher metadata
salt
authenticated encryption envelope
creation timestamp
item count

That is a much better design than "just encrypt some bytes and hope future versions remember how." Explicit metadata makes forward migration, compatibility handling, and debugging safer.

Current backup writer emits a structured object like:

return {
  'v': _backupSchemaVersion,
  'envelope': {
    'format': 'onerule-backup',
    'version': 'v3',
    'algorithm': _gcmAlgorithmName,
    'nonce': base64UrlEncode(secretBox.nonce),
    'cipherText': base64UrlEncode(secretBox.cipherText),
    'tag': base64UrlEncode(secretBox.mac.bytes),
  },
  'salt': base64UrlEncode(salt),
  'kdf': {
    'algorithm': 'PBKDF2-HMAC-SHA256',
    'iterations': _pbkdf2Iterations,
    'keyBits': 256,
  },
};

That snippet captures design philosophy well: crypto parameters travel with container, not only with developer memory.

Import path is also backward-compatible with:

current .enc encrypted backups
legacy .onerule extension
previous schema v: 2
previous schema v: 1, including legacy CBC layout

Again, the pattern here is versioned crypto container plus explicit readers, not hidden magic.

Panic PIN and Privacy Flow

Panic mode is one of the more interesting product decisions because it crosses UX, threat modeling, and implementation details.

OneRule supports a separate Panic PIN verifier. When this flow is used, the app avoids exposing the real vault and enters a privacy-focused decoy mode.

There are two implementation details worth noting:

provider state sets panic mode and suppresses real vault data
home screen renders decoy credential entries for that mode

That means panic mode is not implemented as "delete everything" or "rename list to empty." It is an explicit alternate UI and state flow.

This is a subtle but meaningful distinction. Security-sensitive UX should not depend on the user remembering whether a blank screen is real, broken, or intentional.

The app also warns users that panic mode is a decoy flow and can be confusing if triggered accidentally. That kind of warning is good product engineering. Safety features that are easy to misunderstand become liabilities.

Android Autofill Boundary

Password managers live or die on ergonomics, and Android Autofill is one place where architecture decisions show up clearly.

OneRule uses a native Android AutofillService for API 26+ and bridges it from Flutter over a platform channel. The relevant boundary is important:

Flutter owns normal vault UX and decrypted entry access after unlock
Flutter syncs an encrypted credential snapshot to native storage
Flutter also provides a session key to native layer for active unlock window
native Autofill service performs decryption only when it needs to fill a request

That means Autofill is not backed by a permanently stored plaintext cache. Instead, encrypted envelopes are synced to native side, and usable decryption depends on active session state.

The platform methods reflect that design:

syncAutofillCredentialSnapshot
setAutofillSessionKey
clearAutofillSessionKey

If session key is cleared on lock/logout, Autofill stops returning datasets.

Flutter side bridge is intentionally thin:

Future<void> syncCredentialSnapshot({
  required String payload,
  required String sessionKeyBase64,
}) async {
  final state = await availability();
  if (state != AutofillMvpAvailability.available) {
    return;
  }
  await _bridge.setSessionKey(sessionKeyBase64);
  await _bridge.syncCredentialSnapshot(payload);
}

That sequence matters. Native side receives encrypted snapshot plus active session key only when feature is available and vault is in usable state.

This is a strong boundary design because it minimizes plaintext residency and ties Autofill usefulness to vault unlock state rather than treating Autofill as a separate always-on data channel.

Locking, Clipboard, and Leakage Controls

Security work is often ruined by small post-decrypt leaks rather than broken cryptography.

OneRule includes several controls in this category:

screenshot prevention and screen-capture leakage protection on mobile
auto-lock timeout based on app lifecycle transitions
clipboard auto-clear after configurable delay
optional application of clipboard policy to usernames as well

The lifecycle lock path is especially relevant in Flutter apps, where it is easy to focus on route state and forget process state. OneRule tracks pause/resume transitions and clears session state when idle time exceeds configured threshold.

The relevant branch in lifecycle observer is simple and effective:

if (diff.inSeconds > timeoutSeconds) {
  storage.clearSessionKey();
  unawaited(PlatformCredentialProvider().onVaultLocked());
  unawaited(context.read<PasswordProvider>().lockForSession());
  Navigator.of(context).pushAndRemoveUntil(
    MaterialPageRoute(builder: (_) => const LoginScreen()),
    (_) => false,
  );
}

That is exactly kind of code I like seeing in security-sensitive mobile apps: short, direct, and tied to explicit state invalidation.

That is not glamorous, but it is real security work.

Vault Health Analysis

OneRule also includes a local "Vault Health" analyzer. This is not cryptography, but it is useful security-adjacent logic.

The current report model scores the vault from 0 to 100 based on:

weak passwords
exact-match duplicate passwords
stale credentials

Duplicate detection uses local hash-based comparison logic rather than remote checks, which keeps analysis offline and aligned with rest of system design.

This is a good example of how offline-first does not need to mean feature-light. You can still deliver useful security insights locally if the data model and processing path are designed for it.

Why Flutter Works Here

Security software is often assumed to require fully native implementation, but OneRule is a good example of when Flutter is enough for most of stack and native code is reserved for true platform edges.

Flutter handles:

application UI
state management
settings and backup flows
vault rendering and search
generator and health screens

Native Android handles:

Autofill service
platform-specific storage and bridge responsibilities
native crash logging hooks

That is a practical split.

Flutter gives fast iteration and a unified codebase. Native code stays focused on surfaces where Android APIs are non-negotiable. For a solo-built security product, that balance can make a big difference in maintainability.

Threat Model Boundaries

Good security writeups should include limits, not only protections.

OneRule is designed to defend against:

offline access to copied app data without the derived key
theft or exfiltration of encrypted database files
tampering of AES-GCM protected vault fields and backups

It is not designed to fully defend against:

rooted or fully compromised operating systems
malware with runtime access while vault is unlocked
PIN disclosure by user coercion, phishing, or keylogging
clipboard interception before auto-clear executes

That is a reasonable and honest scope. Offline encryption can do a lot. It cannot fix a hostile runtime after trust boundary is already lost.

Why This Project Is Interesting

A lot of apps claim privacy because they do not have obvious ads or trackers. OneRule is more interesting than that because privacy is expressed in structure:

no backend dependency for core vault flows
explicit key derivation
versioned encrypted payloads
layered storage protection
local-only backup generation
native Autofill integration without persistent plaintext snapshot model

This is what I like about the project technically. The product promise and implementation choices mostly line up.

That is rarer than it should be.

Closing

If you want to study a Flutter security app that takes local-first architecture seriously, OneRule is worth reading through.

It is not trying to out-feature every cloud password manager. It is solving a narrower problem: how to build a usable password vault where local storage, transparent cryptographic boundaries, and offline operation are first-class constraints rather than marketing copy.

Project links:

GitHub: https://github.com/seralifatih/OneRule
Google Play: https://play.google.com/store/apps/details?id=com.fidevelopment.onerule

If you build security software in Flutter, this kind of project is a useful reminder that "mobile-first" and "security-conscious" do not have to be opposites. With careful boundaries, versioned crypto payloads, and disciplined state handling, a local-first password manager can stay practical without outsourcing trust to infrastructure.

How I Built LoopSignal: Public Feedback Boards, GitHub Sync, and Changelogs for Indie Developers

Fatih İlhan — Tue, 07 Apr 2026 04:40:22 +0000

If you are building a SaaS, user feedback usually ends up everywhere except the one place where it is actually useful.

Some requests arrive through email. Some show up in support chats. A few land in GitHub issues. One power user sends a long DM. Then roadmap time comes around and you realize you are mostly guessing.

That frustration is what led me to build LoopSignal.

LoopSignal is a lightweight feedback platform for indie developers and small teams. It gives every product a public board where users can submit ideas and vote on requests, a public changelog to show what shipped, a widget you can embed inside your app, and a GitHub integration that connects feedback directly to development work.

The goal was simple:

Make feedback easy to collect.
Make prioritization obvious.
Make it easy to show users that their feedback mattered.

That last part is the reason for the name. I did not just want a feature request board. I wanted a tool that closed the loop.

The problem I wanted to solve

Most feedback tools I looked at fell into one of two buckets:

They were powerful, polished, and priced for larger product teams.
They were simple, but too limited or too disconnected from a developer-led workflow.

For indie hackers and small SaaS teams, that leaves an awkward gap.

You do not need an enterprise product suite just to answer questions like:

What are users asking for most often?
Which requests are repeated by multiple customers?
What should I build next?
How do I tell users their request is now shipped?

You need a system that is small, fast, and opinionated in the right ways.

I wanted something that let me:

collect feedback without forcing end users to create accounts
let people vote so demand becomes visible
moderate low-quality or spammy posts
push approved requests into GitHub automatically
publish a changelog from shipped work
drop a widget into any app with one script tag

That became the product spec for LoopSignal.

What LoopSignal does

At a high level, each project in LoopSignal gets its own public feedback workflow.

Here is what that includes today:

Public feedback boards where users can submit feature requests and vote on existing ones
Anonymous participation so end users do not need accounts just to leave feedback
Workflow states like Open, Planned, In Progress, Completed, and Closed
Moderation and spam checks to keep the board usable
GitHub integration that creates issues from approved feedback
GitHub webhook sync so closing an issue can mark the related request as completed
Public changelog pages generated from shipped work
Embeddable widget that works with a single script tag
Email notifications when a request changes status
Team roles for owner, admin, and member access
Analytics and CSV export so teams can understand what is happening on the board
API access for teams that want to script or automate around it

The workflow I cared about most looked like this:

A user submits feedback from a public board or an in-app widget.
Other users vote on it.
The team reviews and approves it.
LoopSignal creates a GitHub issue automatically.
The issue gets worked on in the normal development flow.
When the issue is closed, the feedback item becomes completed and shows up in the public changelog.

That is the whole product in one loop.

Why I built it for developers first

A lot of feedback tools are built like product management software. That makes sense for larger organizations, but it also creates friction for small teams.

Small teams do not want another heavyweight system to maintain. They want something that fits the tools they already use.

That is why LoopSignal is intentionally developer-friendly:

GitHub is a first-class part of the workflow
the widget is just a script tag
the product exposes basic API endpoints
the public board is simple enough that users can start contributing immediately

I wanted the setup to feel closer to "connect repo, share link, start collecting signal" than "spend a week configuring a process."

The stack behind it

I built LoopSignal with a stack that is well suited to founder-led SaaS products:

Next.js 15 for the app, routing, server rendering, and server actions
React 19 for the UI layer
Supabase for Postgres, auth, and database access
Cloudflare Workers for deployment via OpenNext
Paddle for billing
Resend for transactional emails
Tailwind CSS + shadcn/ui for the UI

This stack gave me a nice balance:

fast iteration
a single TypeScript codebase
no separate backend service to maintain
enough structure to support auth, billing, and multi-project access cleanly

How the core product flow works

1. Public submission without account friction

One of the easiest ways to kill feedback volume is to ask users to create an account before they can submit an idea.

LoopSignal avoids that. Users can submit feedback from the public board or embedded widget with an optional email if they want updates later.

The submission flow does a few things before a post is created:

validates the title and description
rate-limits submissions
runs a simple spam scoring pass
stores the post as pending for moderation
auto-subscribes the submitter for future status emails

Here is the heart of that server action:

const spam = checkSpam({ title, description, email, ip });
if (spam.isSpam) {
  await logSpam(ip, "spam_detected", spam.signals, spam.score, {
    title,
    description,
    email,
  });
  return { error: "Your submission was flagged." };
}

const { data: newPost } = await admin
  .from("posts")
  .insert({
    project_id: projectId,
    title,
    description,
    category,
    email: email || user?.email || null,
    ip,
    spam_score: spam.score,
    moderation_status: "pending",
    workflow_status: "open",
  })
  .select("id")
  .single();

It is intentionally simple. The product is optimized for useful signal, not for forcing people through a heavy workflow.

2. Voting as lightweight prioritization

Once a post is approved, it appears on the public board where users can vote on it.

That matters because raw feedback is noisy. Voting turns isolated requests into visible demand. It gives teams a better signal than the loudest customer email.

On the public board, users can:

sort by most voted or newest
filter by status
filter by category
open individual request pages
see admin replies directly under posts

That keeps the board useful as it grows instead of turning into a long unstructured list.

3. GitHub issue creation on approval

The most important product decision I made was to connect approved feedback directly to GitHub.

Once a request is approved, LoopSignal can create a GitHub issue automatically for the selected repository. The issue body includes the feedback description and gets labeled as feedback, plus the category if one exists.

This is the core issue creation logic:

const body = [
  description || "",
  "",
  "---",
  "*Created from LoopSignal feedback*",
].join("\n");

await fetch(`https://api.github.com/repos/${owner}/${repo}/issues`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${githubToken}`,
    Accept: "application/vnd.github+json",
    "Content-Type": "application/json",
    "User-Agent": "LoopSignal",
  },
  body: JSON.stringify({ title, body, labels }),
});

This sounds small, but it changes the product from "a place where ideas go to sit" into "a place where ideas can enter the actual engineering workflow."

4. Closing the loop with GitHub webhooks

Creating an issue is only half the story.

The more interesting part is the reverse sync. When a GitHub issue is closed, LoopSignal looks up the linked post and updates the workflow status to completed. If the issue is reopened, the post moves back to open.

That logic is intentionally tiny:

if (action === "closed") {
  workflowStatus = "completed";
} else if (action === "reopened") {
  workflowStatus = "open";
}

This is one of my favorite parts of the app because it removes a manual step. Teams do not have to remember to update the feedback board after shipping. Their existing development workflow updates it for them.

5. Public changelog generation

Once a post reaches a shipped state, it can appear on the project's public changelog page.

That matters because collecting feedback is only half the job. Users need to see that something happened because they spoke up.

A good changelog does a few things at once:

shows active development
builds trust with current users
gives potential customers confidence that the product is alive
makes submitters more likely to contribute again

In LoopSignal, the changelog is just another view of the same underlying feedback data. That keeps the system simple and makes the "close the loop" story visible.

6. Embeddable widget with one script tag

I also wanted the product to work inside existing apps without requiring a deep integration.

That led to a simple embed script:

<script
  src="https://loopsignal.dev/embed.js"
  data-slug="your-project"
  defer
></script>

The script renders an iframe-based widget. It can run in a floating mode with a feedback button or in an inline mode inside a chosen container.

The important part is not technical complexity. It is setup speed. If someone can paste one script and start collecting feedback in two minutes, they are much more likely to actually use the feature.

A few implementation details I cared about

Server actions for mutations

I used server actions for most write operations. For a product like this, they are a good fit:

fewer separate mutation endpoints to manage
direct access to auth context and headers
straightforward cache revalidation with revalidatePath

That made actions like submitting feedback, voting, updating statuses, and managing settings feel compact and easy to reason about.

Supabase for auth and data, but with careful access checks

Supabase gave me a lot quickly:

Postgres
auth flows
admin access for privileged operations

But once team-based access enters the picture, things get more complicated. Ownership, admin permissions, member permissions, public access, and API access all intersect in subtle ways.

I ended up centralizing access checks in auth helpers so permission logic was not duplicated all over the app. That was much easier to maintain than sprinkling project ownership checks throughout every action and page.

Simple anti-spam instead of overengineering

For public boards, spam is not optional. If anyone can submit, someone eventually will submit garbage.

Instead of starting with a complicated external moderation service, I began with a simple scoring system:

all-caps titles
too many URLs
repetitive characters
suspicious email patterns
known spam phrases

That is enough to block obvious junk while keeping the product lightweight.

Basic API surface for power users

LoopSignal also exposes a small API:

GET /api/v1/[slug]/posts
POST /api/v1/[slug]/posts
GET /api/v1/[slug]/stats

The write endpoint uses an x-api-key header and is gated to the Pro plan. I wanted the API to be useful for simple automation without expanding the scope into a huge platform surface area too early.

The hardest parts of building it

No SaaS build is complete without a few annoying edges.

Here are the biggest ones I ran into:

1. Deployment on Cloudflare Workers

Running Next.js 15 on Cloudflare Workers is possible, but not frictionless. OpenNext helps a lot, but you still have to think about environment assumptions, missing Node APIs, and deployment quirks.

I like the performance and cost profile, but it definitely required more care than a default Vercel deployment.

2. Permissions get complex fast

The moment a product supports:

project owners
admins
members
public users
API clients

...your permission model gets real very quickly.

What looks simple at the UI level can turn messy in the backend if you do not centralize access control early.

3. Billing logic touches more of the app than you expect

Billing was one of those features that looked isolated at first and then ended up touching a lot of product behavior:

project limits
team member limits
Pro-only analytics
Pro-only API access
expired trial handling

That is a good reminder that billing is rarely "just a checkout page."

What I learned from building LoopSignal

The biggest lesson was that product scope matters more than feature count.

It would have been easy to keep adding "nice to have" ideas:

more integrations
custom branding controls everywhere
more advanced automation
internal product planning features

But the product gets stronger when the core loop stays obvious:

collect feedback -> validate demand -> sync to development -> show what shipped

Everything in LoopSignal is there to support that loop.

The second big lesson is that feedback products live or die on friction.

If users need too many steps to submit feedback, they will not do it.
If teams need too many steps to act on feedback, they will ignore it.
If nobody sees what shipped, the system does not build trust.

Reducing friction at each of those points mattered more than adding complexity.

Who I built it for

LoopSignal is aimed at:

solo founders
indie hackers
small SaaS teams
developer-led products that already live in GitHub

It is not trying to be an all-in-one enterprise product management platform.

It is trying to be the fastest way for a small team to go from scattered user requests to a visible, structured product feedback workflow.

Pricing reflects that:

Starter: $19/month
Pro: $49/month
14-day free trial with full Pro access

The Starter plan covers the public board, changelog, widget, GitHub integration, notifications, and CSV export. Pro adds things like API access and analytics, plus unlimited projects and team members.

Final thoughts

I built LoopSignal because I wanted a feedback tool that fit the way small teams actually work.

Not every product needs a giant roadmap suite. Sometimes you just need one clear place to collect requests, let users vote, connect the important ones to GitHub, and show people that you shipped what mattered.

That is what LoopSignal is for.

If you want to check it out, the product is live at loopsignal.dev. I am also dogfooding it by collecting feedback about LoopSignal on LoopSignal itself, which felt like the right way to launch a product like this.

I Built 3 APIs for Turkey’s Used-Car Market with Apify

Fatih İlhan — Mon, 06 Apr 2026 08:37:59 +0000

Turkey’s used-car market is massive, fragmented, and surprisingly hard to work with if you want structured data.

Listings live across marketplaces, dealer pages are inconsistent, pricing changes fast, and even simple questions like “What is this car worth?” or “Which dealers dominate Istanbul for this brand?” are harder than they should be.

So I built three focused APIs on top of Apify to solve different layers of the problem:

A listing extraction API for Arabam
A valuation API for Arabam + Sahibinden
A dealer intelligence API for Arabam + Sahibinden

All three are built for developers, analysts, insurers, lenders, marketplaces, and automotive businesses that need clean Turkish vehicle data instead of brittle scraping scripts.

1. Arabam.com Vehicle Scraper API

The first API is the raw data layer.

It extracts structured used-car listings from Arabam.com, including title, make, model, year, price, mileage, fuel type, transmission, city, seller type, and optional detail-page enrichment like condition and seller metadata.

This is the API you use when you want the source-of-truth listing data itself.

Typical use cases:

building your own vehicle marketplace dataset
monitoring listing supply for a specific make/model
collecting comps for downstream analysis
feeding machine learning or BI pipelines

Example input:

{
  "searchUrls": [
    "https://www.arabam.com/ikinci-el/otomobil/volkswagen-passat"
  ],
  "maxListings": 5,
  "scrapeDetails": true
}

Example output fields:

{
  "listingId": "38718353",
  "title": "Galeriden Volkswagen Passat 1.6 TDi BlueMotion Business 2020 Model Mersin 124.000 km Füme",
  "make": "Volkswagen",
  "model": "Passat",
  "year": 2020,
  "price": {
    "amount": 2025000,
    "currency": "TRY"
  },
  "mileage": 124000,
  "fuelType": "dizel",
  "transmission": "yarı_otomatik",
  "city": "Yüksek Mh. Erdemli, Mersin",
  "sellerType": "galeri",
  "url": "https://www.arabam.com/ilan/..."
}

If you need listing-level data, this is the API to start with.

2. Turkish Auto Price Tracker API

The second API is the decision layer.

Instead of returning only listings, it turns listing data into valuation.

You provide a vehicle spec such as make, model, year range, fuel type, and transmission. The API searches Arabam and Sahibinden, then returns:

listing-level price records
median and average price
min/max range
percentiles
seller-type breakdown
mileage-bucket analysis
This is the API for questions like:
What is a 2020 diesel Passat actually worth today?
Is this asking price above market?
How do dealer prices compare to owner-listed prices?

Example input:

{
  "vehicles": [
    {
      "make": "Volkswagen",
      "model": "Passat",
      "yearMin": 2018,
      "yearMax": 2022,
      "fuelType": "dizel"
    }
  ],
  "platforms": ["arabam"],
  "maxListingsPerPlatform": 10
}

Example output includes:

PRICE_RECORD
PRICE_SUMMARY
RUN_SUMMARY

A summary record looks like this in practice:

{
  "type": "PRICE_SUMMARY",
  "totalListingsUsed": 10,
  "overall": {
    "averagePrice": 1839438,
    "medianPrice": 1795750,
    "minPrice": 1525000,
    "maxPrice": 2169000
  }
}

This is the most business-friendly API in the set because it converts raw marketplace noise into a usable market signal.

3. Turkish Auto Dealer Intelligence API

The third API is the market structure layer.

This one focuses on dealers rather than individual cars.

It can scrape direct dealer URLs or discover dealers by city and then return structured dealer profiles with:

dealer name
city and district
contact details
trust/profile signals
optional inventory analysis

That inventory mode is especially useful because it summarizes what a dealer is actually selling:

total listings
average price
median price
price range
fuel breakdown
inventory composition

Example input:

{
  "platforms": ["arabam"],
  "searchByCity": "istanbul",
  "maxDealers": 3,
  "includeInventory": false
}

Example dealer output:

{
  "type": "DEALER_PROFILE",
  "dealerName": "CM MOTORS",
  "city": "İstanbul",
  "district": "Fatih Oto Galeri",
  "phone": "(0539) 812 32 20",
  "dealerUrl": "https://www.arabam.com/galeri/cm-motors-istanbul"
}

And with inventory enabled:

{
  "inventory": {
    "totalListings": 6,
    "averagePrice": 573483,
    "medianPrice": 654000,
    "priceRange": {
      "min": 259000,
      "max": 789000
    }
  }
}

This is the API for:

dealer benchmarking
lead generation
market mapping by city
inventory strategy analysis
B2B automotive intelligence

Why split this into 3 APIs?

Because these are three different jobs.

Listing extraction is about raw data.
Price tracking is about market valuation.
Dealer intelligence is about competitive structure.

Trying to force all of that into one giant “automotive scraper” would make the product harder to understand, harder to price, and harder for developers to integrate.

Three narrower APIs make the value proposition much clearer.

One more important point: these APIs are open source, and contributions are welcome. If you want to improve marketplace coverage, harden parsers, expand normalization, add new output fields, improve dealer analytics, or help support more Turkish automotive workflows, you can jump in and contribute. I want this to become a practical open data tooling layer for the Turkish automotive ecosystem, not just a closed product.

Final thought

Turkey’s automotive market has a lot of publicly visible data, but not a lot of clean, reusable interfaces.

That’s the gap these APIs are designed to fill.

If you want listing-level data, use the vehicle scraper.
If you want valuation, use the price tracker.
If you want dealer-level market intelligence, use the dealer intelligence API.

That stack gives you a practical data layer for the Turkish used-car market without rebuilding the scraping and normalization work from scratch.

I Built 3 APIs for Turkish E-Commerce Intelligence on Apify

Fatih İlhan — Sat, 04 Apr 2026 19:50:15 +0000

If you want structured product, seller, and review data from Turkish marketplaces, you usually end up stitching together brittle scrapers, inconsistent schemas, and platform-specific quirks.

We decided to package that work into three production-ready Apify Actors that behave like APIs:

N11 Product Scraper
Turkish Marketplace Seller Intelligence
Turkish E-Commerce Review Aggregator

You send JSON input. You get clean, structured output. No custom parser per marketplace. No manual normalization step after the crawl. No guessing what the data shape will look like.

The problem with Turkish marketplace data
Turkish e-commerce is large, active, and fragmented.

The hard part is not just collecting pages. The hard part is turning marketplace data into something you can actually use for pricing analysis, seller evaluation, competitor tracking, or product research.

A few examples:

Product pages and listing pages expose different fields.
Seller profile pages vary wildly across Trendyol, Hepsiburada, and N11.
Review systems are inconsistent, especially once you try to normalize rating scales and optional metadata.
Even when you can scrape the page, the output is often too messy to plug into dashboards, alerts, or downstream AI workflows. That’s the gap these actors are meant to close.

What I built

N11 Product Scraper This actor extracts structured product data from N11 search results, category pages, and direct product URLs.

It returns records like:

product title
brand
current price and original price
rating and review count
seller name and seller URL
category breadcrumb path
image URLs
stock status
specifications
description when available A real output record looks like this in practice:

{
  "platform": "n11",
  "productId": "61465",
  "title": "Logitech MK270 Kablosuz USB Turkce Q Klavye Mouse Seti",
  "price": {
    "amount": 1329.9,
    "currency": "TRY"
  },
  "sellerName": "PETCOM",
  "sellerUrl": "https://www.n11.com/magaza/petcom",
  "inStock": true
}

That makes it useful for:

catalog intelligence
price monitoring
seller mapping
assortment comparison
marketplace research Pricing: $5 per 1,000 product records

Turkish Marketplace Seller Intelligence Products are only half the story. On marketplaces, the seller is often the real unit of analysis.

This actor normalizes seller and store profiles across:

Trendyol
Hepsiburada
N11
It extracts fields like:
seller name
seller URL
overall rating
total products
follower count
badges
member since
public business details when available
A sample output looks like:

{
  "platform": "n11",
  "sellerId": "petcom",
  "sellerName": "PETCOM",
  "sellerUrl": "https://www.n11.com/magaza/petcom",
  "overallRating": 5,
  "totalProducts": 20,
  "badges": [
    "Basarili Magaza",
    "Hizli Gonderim",
    "Ucretsiz Kargo"
  ]
}

This is the actor for teams doing:

supplier evaluation
marketplace seller scoring
brand monitoring
competitive intelligence
partner screening Pricing: $8 per 1,000 seller profiles

Turkish E-Commerce Review Aggregator Reviews are where marketplace data becomes operational.

This actor pulls reviews from Trendyol, Hepsiburada, and N11 into one unified schema and adds basic Turkish sentiment tagging.

Each review record includes:

product URL
product title
reviewer name
rating
title
review body
review date
helpful count
images
seller name
variant info
sentiment tag

Example:

{
  "platform": "n11",
  "productTitle": "Logitech MK270 Kablosuz USB Turkce Q Klavye Mouse Seti",
  "reviewerName": "M*** O***",
  "rating": 5,
  "body": "Iyiydi",
  "sentimentTag": "positive",
  "sellerName": "Techburada"
}

This is useful for:

sentiment analysis
product feedback monitoring
seller quality tracking
review mining
competitor product research Pricing: $3 per 1,000 reviews

Why these three actors work better together
Individually, each actor solves a clear problem.

Together, they give you a compact Turkish e-commerce intelligence stack.

A simple workflow looks like this:

Use the N11 Product Scraper to collect products in a category.
Extract seller URLs from those product records.
Pass those seller URLs into Seller Intelligence.
Pass the product URLs into Review Aggregator.
Join the outputs on product URL and seller URL. Now you can answer questions like:

Which sellers dominate a category?
Which sellers have strong trust signals but weak review sentiment?
Which products are priced aggressively but getting poor feedback?
Which brands are present across multiple sellers with inconsistent review patterns? That is much more useful than a raw HTML scraper.

Designed like APIs, not like hobby scripts
A lot of scrapers stop at “it works on my machine.”

These actors were built to behave more like production APIs:

input validation with clear English errors
normalized output schemas
progress logging
partial completion handling
final run summaries
deployment-ready on Apify
clean dataset outputs for downstream systems
That matters if you want to use them from:
internal tools
BI pipelines
LLM workflows
agent systems
scheduled monitoring jobs
enrichment pipelines
Why Apify
Apify is a strong fit for this category of product because it gives users a clean way to run, schedule, and consume data extraction jobs without managing crawler infrastructure.

That means users can treat these actors as ready-to-use APIs:

send input
run actor
read dataset output
plug into the next workflow And because output schemas are defined, the results are easier for both humans and AI agents to understand and chain.

Who these are for
These actors are a good fit for:

e-commerce operators in Turkey
agencies doing marketplace monitoring
brands tracking sellers and reviews
sourcing teams evaluating sellers
analysts building category intelligence dashboards
founders building vertical data products on top of Turkish commerce data The pitch, simply put Turkish marketplace data is valuable, but annoying to operationalize.

These three actors turn it into something you can actually use:

product records
seller profiles
normalized reviews with sentiment If you work on Turkish e-commerce intelligence, you should not have to rebuild this stack from scratch.

That is exactly why I built it.

Available now
N11 Product Scraper

Turkish Marketplace Seller Intelligence
Turkish E-Commerce Review Aggregator

DEV Community: Fatih İlhan

Building LoopSignal Part 2: The Public Board, Voting, and Prioritization Without the Overhead

What the public board needed to do

The page is a server component

Moderation is what makes the board clean

Voting without an account

Optimistic updates in the vote button

Sorting and filtering without full-page reloads

Prioritization without becoming roadmap software

Status labels bridge feedback and roadmap

Admin comments as public replies

What I learned building this piece

What's next

How I Built Instagram Intelligence Suite for IG Growth

Why I split this into three APIs

1. IGLead: qualifying influencer and creator profiles before outreach

Example IGLead input

What comes back

2. IG_story_snapshot: monitoring story activity without owning the account

Example IG_story_snapshot input

What comes back

3. IG_comment_lead: turning Instagram comments into lead intelligence

Example IG_comment_lead input

What makes this one interesting

How the three APIs work together

Implementation notes

What I would improve next

Final thoughts

Building LoopSignal Part 1: Anonymous Feedback Submission in Next.js 15

The problem with most feedback forms

What the submission flow needed to do

Why anonymous submission mattered

The data model

Why I used a server action for submission

Moderation was not optional

Anti-spam without overengineering it

Optional email was better than required auth

One subtle thing this unlocked later

What I learned from building this piece

What's next

Why Every AI Developer Should Try the `caveman` Repo (Even If It Looks Like a Joke)

What Is Caveman?

The Real Problem: AI Is Too Polite

What Benefits Do You Actually Get?

1. Massive Token Savings

2. Faster Responses

3. Higher Signal-to-Noise Ratio

4. Surprisingly Easy to Install

Why This Repo Went Viral

One Important Caveat

When Caveman Is Actually Useful

Final Thoughts

I Built a Trading Signal Engine That Reads Congressional Insider Trades — Here's the Architecture

The Problem: Raw Insider Data Is Mostly Noise

Stack

Architecture

The 7-Filter Stack

Filter 1: Purchases Only

Filter 2: Filing Delay ≤ 7 Days

Filter 3: Minimum Size ≥ $50K

Filter 4: Relevance — Committee Match or C-Suite

Filter 5: Cluster Detection

Filter 6: No Earnings Gamble (Async)

Filter 7: Technical Check (Stub — Phase 2)

The Scoring Model (0–100)

Data Model: Three Core Tables

The Ingestion Pipeline

What Makes This Different From Just Using Quiver

Phase Roadmap

Competitive Moat

Key Technical Decisions

What's Next

Building OneRule: A Technical Deep Dive into an Offline Password Manager with Flutter, SQLCipher, and AES-GCM

Architectural Shape

Data-at-Rest Model

Key Derivation and Session Model

Why SQLCipher Plus Field-Level AES-GCM?

Vault Migration Strategy

1. Legacy vault backend migration

2. Legacy cipher format migration

Example `IGLead` input

Example `IG_story_snapshot` input

Example `IG_comment_lead` input