DEV Community: Kumar Kislay

The One Command That Halved My Anthropic Bill Overnight

Kumar Kislay — Thu, 02 Jul 2026 12:23:12 +0000

Last month my Anthropic bill was $312. I use Claude Code for 6-8 hours daily across multiple projects. After adding a single line to my shell config, this month's projected bill is $94. Same usage patterns. Same quality of output. Same number of sessions.

The difference: I stopped sending redundant tokens to the API. That is it. No workflow changes. No prompting tricks. No switching to a cheaper model.

Here is the full breakdown of what happened and how you can do the same thing in 60 seconds.

The Setup (Literally 60 Seconds)

pip install copium-ai
copium wrap claude

That is it. Two commands. Now every Claude Code request routes through a local compression proxy before hitting the API. My prompts get 40-80% smaller. Same answers come back.

Where My Tokens Were Going

I ran copium stats --period month after the first week and saw the breakdown:

Most of my wasted tokens came from duplicate file reads (180K → 12K, 93% savings), JSON tool outputs (320K → 64K, 80%), build logs (95K → 14K, 85%), search results (150K → 30K, 80%), conversation history (200K → 140K, 30%), and tool schemas (45K → 8K, 82%). Overall, my daily input dropped from 990K tokens to just 268K, a 73% reduction.

The Cost Breakdown

Anthropic Claude Sonnet pricing:

Input: $3 per million tokens
Output: $15 per million tokens (unchanged by compression)
Cached input: $0.30 per million tokens (90% discount)

My savings come from two sources:

Fewer input tokens (compression)

More cache hits (prefix stabilization)

Daily input tokens dropped from 990K to 268K, while my cache hit rate increased from 12% to 48%. That reduced my effective input cost from $2.90/day to just $0.62/day. Output costs stayed the same at $7.50/day, bringing my total daily cost down from $10.40 to $8.12.

Wait, that is only $68/month savings on raw math. Where does the $200 come from?

The bigger savings: I stay in sessions longer without hitting compaction. Before compression, long sessions hit compaction at 35 turns, forcing context loss and repeated work. Now sessions last 55+ turns productively. Fewer repeated file reads, fewer redundant tool calls, fewer wasted output tokens on re-doing work.

Does Quality Actually Stay the Same?

I was skeptical too. Here is what I measured over 4 weeks:

Code that compiles first try: 78% (before) vs 76% (after) = within noise
Tests passing on first run: 62% vs 60% = within noise
"Agent forgot something" incidents: 4.2/week (before) vs 1.1/week (after) = BETTER

The last metric surprised me. Compression actually IMPROVED context management because the agent's context window was not overflowing with garbage.

What If I Have a Copilot Subscription?

Subscription users do not pay per token directly, but you still benefit:

Longer productive sessions (context does not fill up)
Fewer "I need to start a new chat" moments
Better quality in long sessions

Copium

Copium (http://github.com/iKislay/copium) is open source (Apache 2.0) and runs entirely locally. Your code never leaves your machine. It adds about 50ms of latency per request, which is invisible compared to the 2-30 second LLM response time.

The key features that matter for cost savings:

Zero-config proxy (copium wrap <agent>)
Session deduplication (catches repeated file reads)
SmartCrusher (compresses JSON tool outputs 70-90%)
Progressive tool disclosure (reduces schema tokens 75-95%)
Cache alignment (increases provider cache hits 3-4x)
Quality gate (auto-reverts if compression hurts quality)

Quick ROI Calculation

Time to set up: 60 seconds

Monthly cost of tool: $0 (open source)

Monthly savings: $150-200 (per developer)

Payback period: Immediate

There is no reason not to try it. If it does not help your workload, copium unwrap claude removes it in one command.

Tool: http://github.com/iKislay/copium

Your Resume Gets You Seven Seconds. Here's What Gets You Twenty Minutes.

Kumar Kislay — Tue, 30 Jun 2026 06:13:03 +0000

A few years ago, every career conversation started with one question.

"Can you send me your resume?"

In 2026, that question is slowly changing.

The Story

Last week, a friend of ours who works in HR at a startup in Kolkata came across two fresher profiles for the same role.

Same year of graduation. Similar coursework. On paper, nearly identical.

Candidate A had a beautifully designed two-page resume. Every section polished. Every skill listed. Every achievement quantified. The kind of resume that looks like it took hours to format.

Candidate B had a simple resume. Nothing fancy. But alongside it, there was a profile.

Not a beautifully designed personal website. Just real work, laid out clearly. Projects that could be clicked and tried. Problems that were actually solved, with the reasoning behind them. Code that could be reviewed. An article that had been published. A small tool with real users.

The recruiter spent less than a minute on Candidate A's resume.

She spent nearly twenty minutes on Candidate B's profile.

What Actually Happened There

Resumes tell people what you've done.

Profiles show people what you can do.

That difference sounds small. It is not. One is a claim. The other is evidence. And recruiters, whether they admit it or not, trust evidence far more than claims.

This is not a new idea. It is just becoming impossible to ignore.

A resume can say "built scalable systems," "led cross-functional projects," "delivered measurable impact." Every resume says some version of this. It has become noise. Recruiters have read the same five phrases ten thousand times.

A profile does not make claims. It shows the thing. The recruiter clicks, sees it work, reads the reasoning, and forms a judgment based on something real. That is a fundamentally different kind of trust.

Does This Mean Resumes Are Dead?

No. And we want to be honest about that.

A resume is still your entry ticket. It helps a recruiter quickly understand your background, your timeline, your basic qualifications. It is fast, structured, and familiar. Nobody is suggesting you delete it.

But here is the part that has genuinely shifted.

In a world where AI can generate a polished, keyword-optimized, perfectly formatted resume in about ninety seconds, the resume alone has stopped being a differentiator. Everyone's resume looks competent now. That is exactly the problem. Competent and identical is not a signal anymore.

What cannot be generated by a prompt is your actual track record. Your GitHub history. The product you shipped and the users who actually use it. The case study explaining a hard decision you made and why. The blog post that shows how you think. The side project you built because something annoyed you and you fixed it.

These are becoming stronger signals than a list of bullet points, because they cannot be faked the way a sentence can.

Why This Matters More for Builders Specifically

If you are a developer, a designer, a founder, or anyone building things in tech, you are in an unusually good position here. Most professions cannot show their actual work easily. Developers can. You can deploy something for free, document it properly, and let anyone in the world click through it.

The problem most builders have is not a lack of proof of work. It is that the proof is scattered.

A project here. A GitHub profile there. A blog post somewhere else. A startup update buried in an old LinkedIn post. None of it connected. None of it presented as a coherent professional identity. A recruiter or collaborator has to do the work of stitching these fragments together, and most of them will not bother.

This is the exact gap Forg was built to close.

A forg.to profile is not a resume and it is not a static portfolio site you build once and forget. It is a living professional record. Your products. Your milestones. Your shipped work, verified metrics, and ongoing activity, all in one place that updates as you build. The kind of profile that, if a recruiter landed on it, would hold their attention for twenty minutes instead of forty seconds.

That is the entire premise. Not where you've worked. What you've built.

The Real Answer Is Not Either/Or

In 2026, the strongest combination is not resume versus profile.

It is resume plus profile.

One gets you noticed in the first seven seconds of a scan. The other gets you remembered for the twenty minutes after that, and it is the twenty minutes that actually decide whether you get the call.

Builders who understand this are not abandoning their resumes. They are pairing a clean, simple resume with a living record of what they have actually built, hosted somewhere a recruiter can explore it without friction.

That pairing is the new baseline. Not the exception. The expectation.

What's Your Take?

If you had to pick only one today, resume or profile, which would you choose?

We think the better question is why you are still choosing.

Build the profile. Keep the resume. Let your work speak for the twenty minutes your resume can never earn on its own.

I Built a JSON Compressor Using Change Point Detection and It Outperforms Every Alternative

Kumar Kislay — Mon, 29 Jun 2026 06:30:05 +0000

Every time your AI coding agent calls a tool, the response is usually a massive JSON array. Think about it. You ask an agent to search your codebase, it returns 500 results. You ask it to list files, it dumps the entire directory tree. You ask it to query a database, it sends back hundreds of rows. And all of that goes into the context window, token by token, dollar by dollar. The LLM reads every single item, even though it only needs maybe 20 of them to answer your question.

I kept watching my token bills climb and realized something. The vast majority of items in these arrays are noise. They follow predictable patterns, they repeat structural signatures, and they contain information the model will never use. So I built SmartCrusher, the statistical compression engine inside Copium (github.com/iKislay/copium), and it consistently removes 70-90% of array items while keeping every piece of information the LLM actually needs.

Here is how it works under the hood.

The Core Insight: Not All Array Items Are Equal

The naive approach to compressing a JSON array is truncation. Take the first N items, throw away the rest. This is what most tools do. But this is terrible because the most relevant items are rarely at the top.

SmartCrusher takes a different approach: statistical relevance scoring. It treats each item in the array as a data point and uses multiple signals to determine which items carry unique information.

The Three Scoring Signals

1. Variance-Based Change Point Detection

I compute a rolling variance window across the array items (serialized to string length and structural fingerprint). When the variance spikes, that indicates a transition between "boring repeated items" and "interesting unique items." These change points get boosted in the relevance score.

def detect_change_points(items: list[dict]) -> list[int]:
    fingerprints = [structural_fingerprint(item) for item in items]
    window_size = max(3, len(items) // 20)
    variances = rolling_variance(fingerprints, window_size)
    return find_peaks(variances, threshold=2.0 * np.std(variances))

2. Kneedle Algorithm for Optimal K

How many items should we keep? This is the hardest question. Too few and the LLM misses context. Too many and you are not saving tokens.

I use the Kneedle algorithm on the sorted relevance scores. Plot the scores from highest to lowest. The "knee" of that curve is where you hit diminishing returns. Items above the knee are worth keeping. Items below contribute marginal information at disproportionate token cost.

from kneed import KneeLocator

scores_sorted = sorted(relevance_scores, reverse=True)
kneedle = KneeLocator(
    range(len(scores_sorted)),
    scores_sorted,
    curve="convex",
    direction="decreasing",
)
optimal_k = kneedle.knee or len(scores_sorted) // 5

3. BM25 + Embedding Relevance

If there is a query context (the user's question, the tool call parameters), SmartCrusher scores each item against that query using BM25 term frequency. For cases where semantic similarity matters more than keyword overlap, an optional embedding similarity pass runs on top.

The final score for each item is a weighted combination:

final_score = (0.4 * change_point_boost) + (0.35 * bm25_score) + (0.25 * embedding_sim)

The Safety Net: CCR Integration

Here is the part I am most proud of. SmartCrusher never permanently deletes anything. Every compressed array gets stored in the CCR (Compress-Cache-Retrieve) store with a SHA-256 hash. The LLM receives the top-K items plus a retrieval marker:

[20 items shown of 1000 total. Retrieve more: copium_retrieve("abc123", "query")]

If the model needs something that was removed, it calls copium_retrieve and gets it. In practice, this retrieval happens less than 3% of the time. The statistical selection is that good.

Performance Numbers

Input Size	Items Kept	Token Savings	Retrieval Rate
100 items	12-18	82-88%	2.1%
500 items	15-25	95-97%	2.8%
1000 items	18-30	97-99%	3.4%

The overhead? SmartCrusher processes 1000 items in under 15ms. The LLM never notices.

Why Not Just Use LLM Summarization?

I tried this first. Ask GPT-4 to summarize the array. Problems:

You are paying tokens to save tokens (negative ROI for small arrays)
Summarization adds latency (2-5 seconds vs 15ms)
The summary is lossy and irreversible. If the LLM needs the original, it is gone
The LLM hallucinates details that were not in the original data

SmartCrusher generates zero new text. Every item in its output existed in the original array, byte for byte. This is crucial for reliability.

The Rust Acceleration

The Python prototype worked but was too slow for real-time proxy use at scale. I rewrote the hot path (fingerprinting, variance computation, kneedle) in Rust and exposed it via PyO3. The Python interface stays clean:

from copium.transforms.smart_crusher import SmartCrusher

crusher = SmartCrusher(max_items=25, relevance_method="hybrid")
compressed = crusher.compress(original_array, query_context="find auth bugs")

But under the hood, the Rust code handles the O(n log n) operations.

Lessons Learned

Statistical methods beat heuristics. My first version used hand-tuned rules ("keep items with error in the text"). SmartCrusher's statistical approach works on any content without domain-specific rules.
Reversibility is non-negotiable. The moment you permanently delete context, you introduce failure modes. CCR makes compression a zero-risk operation.
The Kneedle algorithm is underrated. Finding optimal K without a training set is hard. Kneedle solves it elegantly for sorted score distributions.
BM25 is good enough for 90% of cases. I spent weeks on embedding-based similarity before realizing BM25 handles most tool outputs perfectly. Embeddings help only for semantic queries.

SmartCrusher is the core compression engine in Copium. It handles every JSON array that flows through the proxy, silently saving 70-90% of tokens while the LLM works exactly as if the full data was there.

Source: github.com/iKislay/copium

How Developers Can Show Real Work

Kumar Kislay — Tue, 23 Jun 2026 13:19:40 +0000

Most developers have the same problem.

They know how to build things. They have spent hundreds of hours learning, practicing, shipping. But when it comes to actually showing that work to the people who matter, they fall back on a resume that says "proficient in React" and hope for the best.

The people who get the interviews, the contracts, the interesting projects — they have figured out something different.

They do not describe their work. They show it.

The Thirty-Second Problem

80% of recruiters spend under three minutes reviewing portfolios.

Some research puts it even lower than that. Recruiters spend less than 30 seconds scanning a portfolio before deciding if you're worth an interview.

Thirty seconds.

In that window, a hiring manager is not reading your resume carefully. They are not parsing your bullet points about scalable architectures. They are looking for one thing: a fast, undeniable signal that you can build real things.

The developers who clear that filter are not necessarily better developers. They are the ones who have made their work easy to verify quickly.

The Tutorial Trap

Here is the quiet killer of most developer portfolios.

Someone learns React, follows a tutorial, builds a to-do app. Then another tutorial. Another to-do app with a different color scheme. Maybe a weather widget. Maybe a calculator.

These are fine learning tools. They are genuinely bad portfolio pieces.

Not because the code is bad. Because they do not prove anything a hiring manager does not already assume. Everyone who completed a course built a to-do app. It signals "I completed a tutorial," not "I can solve real problems."

84% of employers want to see working applications, not just code repositories. The distinction matters. A repo is a codebase. A working application is proof that you can take something from code to deployed reality, handle real-world edge cases, think about users, and finish things.

The shift is simple in theory and harder in practice: stop building what tutorials tell you to build and start building what actually solves a problem.

Your own problem is fine. Something that annoyed you. Something that did not exist and should have. Even a small tool that ten people actually use is worth more than a polished to-do app nobody ever touched.

Your GitHub Is a Storefront, Not a Storage Drive

Most developers treat GitHub like a drawer where they throw unfinished experiments.

GitHub profiles with optimized READMEs and consistent commit patterns receive 3x more profile visits and significantly more interview requests.

That is not a small difference.

Your GitHub profile is often the first technical impression you make. The contribution graph, the pinned repositories, the quality of your readmes. A hiring manager or potential collaborator clicks through and forms an impression within seconds.

A few things that actually move the needle:

The profile README. GitHub lets you create a special repository that renders as your profile page. Use it. Introduce yourself, show what you are currently building, link to your work. It takes two hours to set up and pays dividends every time someone lands on your profile.

Pinned repositories. You get six. Use them for your best work, not your most recent. Each pinned repo should have a descriptive name, relevant tags, and a readme that actually explains what the project does and why it exists.

Commit consistency. Not commit volume for its own sake. Regular, meaningful activity over time. A contribution graph with consistent history across months and years says something different than a burst of commits during a job search. One signals a developer who builds continuously. The other signals someone who prepared for an application.

Writing READMEs That Actually Get Read

Complex, well-built projects are invisible without documentation.

A hiring manager is not going to clone your repo, install dependencies, and reverse-engineer your code to figure out what it does. If the README does not explain the project in sixty seconds, they close the tab.

A README that works reads like a product page, not a technical manual.

It answers: what problem does this solve? Here is what it looks like. Here is the tech stack. Here is a live demo. Here is one interesting technical decision I made and why.

That last part is the one most developers skip.

Explaining your tradeoffs is the most powerful signal in a portfolio. Why PostgreSQL over MongoDB? Why did you implement Redis caching? Why did you structure the state management that way?

Portfolios that land interviews don't just list work — they tell a story. A clear narrative helps recruiters follow your thinking and connect with your skills faster.

The story of your technical reasoning is more interesting than the code itself. Anyone can write code. Not everyone can explain why they made the choices they did.

The Backend Developer Problem

Frontend developers have a natural advantage here.

Their work is visual. You can click through it, look at it, experience it. The portfolio almost builds itself.

Backend developers, data engineers, and DevOps specialists have the opposite problem. Their most impressive work is invisible. Optimized database queries, scalable infrastructure, secure authentication flows. None of this is clickable.

The solution is to translate invisible work into visible evidence.

An interactive Swagger or Redoc documentation page for an API you built. A Postman collection anyone can import and run. A system design diagram showing architecture decisions with explanations. Performance metrics: "reduced query latency by 40%," "scaled to handle 10,000 concurrent requests."

Numbers make invisible work visible. Not vague claims like "optimized performance" but specific before-and-after measurements that show what changed and by how much.

A backend developer who can say "here is my API, here is the documentation, here is what happens under load" has a more compelling portfolio than most frontend developers with beautiful UIs and no explanation of what they built.

Open Source: The Highest-Trust Proof of Work

Building personal projects proves you can start and finish something.

Contributing to open source proves something harder: that you can read a large unfamiliar codebase, understand existing patterns, write code that meets someone else's standards, and collaborate with people who have no obligation to be nice about your pull request.

That is a different and more demanding kind of proof.

Even small contributions matter more than they seem. A bug fix in a popular library. A documentation improvement. A minor optimization in a project with real users.

When someone sees a merged pull request in a project they recognize, the credibility transfers. Your code was good enough that the maintainers accepted it. That is peer review. That is real validation.

The Visibility Problem Nobody Talks About

Here is something that does not come up enough in portfolio advice.

You can do all of this correctly and still be invisible.

Strong GitHub profile. Well-documented projects. Open source contributions. Live demos. Real users.

But if none of it is findable as a coherent professional identity, a hiring manager looking at your application for thirty seconds will default to the first clear signal they can read. Which, for most developers, is still a resume.

The fragmentation problem is real. GitHub shows code. A personal site shows selected highlights. LinkedIn shows employment history. None of them show the full picture of an active builder with a consistent track record.

This is exactly the gap that a professional builder profile addresses. On forg.to, a profile is structured around what you have actually built: products, milestones, development activity, and a running record of shipped work. Not a static snapshot. A living professional identity that updates as you build.

When a recruiter or collaborator lands on a profile that shows five shipped products, documented milestones, verified metrics, and ongoing activity, they are not reading claims. They are reading a track record.

The Case Study Layer

Shipping a product is proof of work.

Writing a case study about building it is a different kind of proof entirely.

A case study shows how you think. Not just what you built, but the problem you started with, the decisions that mattered, the things that went wrong, what you would do differently. It shows engineering maturity in a way that code alone cannot.

Employers need to see evidence of how you think, learn, and solve problems. A case study is the clearest possible demonstration of that.

It does not need to be long. Three to four hundred words per project. What the problem was. What made it hard. What you decided. What you learned.

The developers who write these are rare. Which means anyone who does immediately stands out from the majority who just link a GitHub repo and hope for the best.

Making It All Findable

Everything above matters. None of it matters if people cannot find it.

Link your GitHub from your portfolio. Link your portfolio from your LinkedIn. If you have a professional profile on forg.to, link that too. If you write technical posts, link them from everywhere.

Create a web, not islands.

The goal is that when someone is evaluating you, one click from anywhere leads them to the full picture. Not fragments scattered across platforms with no connection between them.

Your portfolio is ultimately a marketing tool and it markets you. A marketing tool that nobody can navigate from one piece to the next is not doing its job.

The Quality Filter

One last thing.
3-5 polished projects outperform 10+ basic ones, according to hiring manager surveys.

This is counterintuitive because more feels like more. It is not.

A portfolio with three excellent, well-documented, well-explained projects signals a developer with taste and standards. A portfolio with fifteen half-finished, undocumented, tutorial-derived projects signals someone who has not thought carefully about what their work says about them.

Curate ruthlessly.

The projects that stay in your portfolio should be the ones you can speak about for twenty minutes without running out of things to say. The ones where something interesting happened, where you made real decisions, where the outcome mattered.

Everything else can be archived.

The Point

Real work is not hard to show. It just requires the habits most developers skip.

Build things that solve actual problems. Document them like a product, not a homework assignment. Explain your reasoning, not just your code. Contribute to projects that already have real users. Make the trail findable and coherent.

The developers who do this consistently end up in a position that feels like luck from the outside.

It is not luck. It is just the compounding effect of making real work visible over time.

The Rise of Proof-Based Hiring

Kumar Kislay — Mon, 22 Jun 2026 02:55:13 +0000

Imagine two developers applying for the same role.

The first has a computer science degree from a mid-tier university, three years at a company nobody remembers, and a LinkedIn profile that says "passionate about building scalable solutions."

The second has no degree. But they have five shipped products, two of them with real paying users, an open source library with 800 GitHub stars, and a public record of two years of consistent building.

For most of the last century, the first candidate got the call.

That is starting to change.

The System That Built Itself Around Paper

Degrees became the default hiring filter for a simple reason: they were convenient.

A bachelor's degree was shorthand for "this person can learn, persist, and follow through." It was a signal that required no verification. The hiring manager did not need to think. The filter did the work.

For decades it held up reasonably well. Careers were slow. Skills were stable. The things you learned in a four-year program stayed relevant long enough to matter.

Then technology happened.

The half-life of a technical skill collapsed. A framework taught in year one of a CS program is sometimes deprecated before graduation. The most relevant skills in software today are things universities are still figuring out how to teach.

The degree started measuring the wrong thing.

The Cracks Started With the Giants

The first loud signal that the credential system was breaking came from the companies everyone was trying to get into.

Google acknowledged something remarkable: college transcripts and test scores are, in their words, "worthless predictors of later job performance."

IBM went further. At some of IBM's US centers, as many as one-third of employees have less than a four-year degree. IBM's CEO wrote that the company is creating "new collar" jobs in areas like cybersecurity, data science, and AI where highly specialised training matters more than a rigid four-year curriculum.

Apple, Netflix, Bank of America, Shopify. The list of companies removing degree requirements grew steadily. Between 2014 and 2023, the number of roles eliminating degree requirements surged four times.

The direction was clear. The pace was not.

The Bombshell Finding Nobody Talks About

Here is where it gets complicated.

In early 2024, Harvard Business School and the Burning Glass Institute published a comprehensive analysis of actual hiring patterns across thousands of companies. What they found should be pinned to every hiring manager's wall.

While 85% of companies talk about skills-based hiring, only 0.14% of hires are actually impacted by degree requirement removal.

Read that again.

85% of companies say they have moved to skills-first hiring. But only 1 in every 700 hires is actually affected.

The study found that even among companies that eliminated degree requirements, only 1 in every 700 hires was a non-degree candidate.

The policy changed. The behavior did not.

The press releases went out. The actual recruiters kept defaulting to what they knew.

This is not a small discrepancy. It is a chasm between what the industry says it believes and what it actually does when a stack of resumes lands on a screen.

But the Underlying Science Is Unambiguous

Despite the gap between rhetoric and reality, the research on what actually predicts success at work is not ambiguous.

McKinsey reports that hiring for skills is five times more predictive of job performance than hiring based on education and more than twice as effective as hiring based on work experience. Employees without degrees also stay in their roles 34% longer than those with degrees.

Five times. Not marginally better. Five times.

In companies where skills-based hiring is fully implemented, non-degree hires have a 10 percentage point higher retention rate over two years than their degree-holding counterparts. These employees also experience a 25% increase in salary growth.

The companies that have actually made the shift are not doing it for ideological reasons. They are doing it because the numbers work.

Research from Harvard Business Review shows that skills-hired employees have 25% higher performance ratings and 40% lower turnover rates compared to traditionally hired counterparts.

The degree was never actually measuring what companies thought it was measuring. It was a proxy. Proof of work is a direct measurement.

What Proof-Based Hiring Actually Looks Like

The shift from credential-based to proof-based hiring is not just about dropping degree requirements.

It is about changing what counts as evidence.

In credential-based hiring, evidence is: where you studied, what companies employed you, what titles you held.

In proof-based hiring, evidence is: what you built, what you shipped, what your work produced in the real world.

For developers specifically, this looks like:

A GitHub profile with real commit history. Not a burst of commits last month. A consistent pattern of work over years that shows someone who writes code regularly, not someone who prepared for a job application.

Live products with real users. A link anyone can click. Something that works, deployed, being used. For web developers, a strong portfolio of live projects can land a role without any formal degree at all.

Open source contributions. Code merged into projects you did not build. Issues filed and resolved. Pull requests reviewed. Evidence that you can collaborate in unfamiliar codebases.

Documented milestones. First users, first revenue, product launches, technical decisions with outcomes attached. The building record that tells a story of how someone works over time.

This is the profile that wins in proof-based hiring. Not because it is impressive on paper, but because it is verifiable in reality.

The Developer Advantage Nobody Is Using

Here is the thing that makes this genuinely remarkable for developers specifically.

Developers can prove their work in a way almost no other profession can.

You can deploy a product for free. Put the code on GitHub. Write about what you built and why. Let anyone in the world interact with what you shipped.

Self-taught coders who acquired the same skills while managing full-time employment can build a more convincing case for work ethic and motivation than a recent computer science graduate with no external projects.

The ability to show your work publicly is extraordinary. Most professions cannot do this. Lawyers cannot litigate in public. Doctors cannot practice online. Developers can build something real and put a URL in their application.

Most developers still send plain PDF resumes.

The gap between what is possible and what most developers actually do is enormous. And for anyone paying attention, that gap is an opportunity.

The Real Shift Happening Beneath the Headline Numbers

The Harvard study showing only 1 in 700 hires is discouraging if you read it as "nothing has changed."

Read it differently: the 0.14% who are breaking through without degrees are doing so because their proof of work is undeniable.

When a developer's public record of shipped products, consistent activity, and documented milestones is strong enough, the degree requirement gets set aside regardless of official policy. Not because the policy changed, but because the proof is sitting right there and the hiring manager is not going to ignore it.

This is the version of proof-based hiring that is already happening. Not institutionally. Case by case, developer by developer, wherever the proof is strong enough to override the default.

In 2026, 85% of US employers use skills-based hiring practices. Amazon alone hired 2,468 bootcamp graduates in 2024, up 129% from two years prior.

The infrastructure is building. The momentum is real. The developers who have been building their proof of work record for the last few years are positioned for a hiring environment that is becoming more favourable to them every year.

Where the Record Lives

The bottleneck for most developers is not the work. It is the visibility of the work.

You can have five shipped products, a GitHub with consistent history, and a real record of building in public. But if none of it is findable in a coherent professional profile, a hiring manager looking at your application for ninety seconds will default to what they can read quickly.

This is why the infrastructure for documenting and presenting proof of work matters.

GitHub handles code. A personal portfolio handles selected highlights. But neither captures the full picture: the products built, the milestones hit, the development activity, the ongoing record of consistent output that tells the story of a developer who ships reliably over time.

Platforms like forg.to are built for exactly this gap. A professional profile structured around what you have built rather than where you have worked. Products, milestones, verified metrics, and a living record that updates as you build. Not a static snapshot. The actual trail of work.

When proof-based hiring is the standard, the developer with a coherent public record of real work has an advantage that no resume can manufacture.

The Honest Reality Check

The transition from credential-based to proof-based hiring is real but uneven.

Large legacy companies still have HR systems that screen for degrees automatically. The recruiter might believe in proof of work. The ATS filters before the recruiter sees the application.

Startups, growth-stage tech companies, remote-first companies, and technically sophisticated hiring managers are already operating in a proof-first world. LinkedIn predicts that by 2030, over 75% of entry-level tech roles will prioritise skills over degrees.

The transition is happening faster in some places than others.

The practical implication: the developers who build their proof of work record now are positioning themselves for both the current environment and the one that is coming. The proof is useful today at the companies already operating this way. It becomes essential as the rest of the market catches up.

What to Do With This

The research is clear. The companies making the shift are seeing better hires, higher retention, and stronger performance. The developers breaking through without traditional credentials are the ones with the most compelling proof of work.

The actionable version of all of this is simple.

Build things. Ship them. Document them publicly. Keep building.

A coherent public record of consistent output across your GitHub, your portfolio, and your professional profile on forg.to is not just a career strategy. It is the correct answer to the question every hiring process is trying to answer: can this person actually build?

The developers who have that answer readily visible are the ones who win in proof-based hiring, regardless of what their educational history says.

The credential was always a proxy for capability.

Proof of work is the capability.

How to Build Profiles for Landing Remote Jobs as a Programmer?

Kumar Kislay — Fri, 19 Jun 2026 10:10:08 +0000

The remote job market is the most competitive hiring environment most developers will ever face.

Not because remote jobs are rare. Because the talent pool is global.

When a company posts a remote role, they are not picking from local candidates. They are choosing from thousands of developers across every timezone. The person they hire could be in Bengaluru, Warsaw, Lagos, or São Paulo.

That changes everything about how you present yourself.

You cannot walk into an office and charm your way through a weak profile. You cannot rely on a warm referral from someone who saw you in person. Before you ever speak to anyone, your profiles have already made a first impression.

In remote hiring, your profiles are doing most of the work.

Why Profiles Do More Work in Remote Hiring

In-person hiring has a lot of compensating factors.

A strong interview performance can overcome a mediocre resume. Body language, energy, presence in the room. These things influence decisions even when they probably should not.

Remote hiring strips most of that away.

A hiring manager screening 200 applicants for a remote role spends two to four minutes per candidate before deciding who to actually talk to. In those minutes they are looking at your GitHub, your LinkedIn, your personal site, maybe your portfolio.

What they see in that window either earns you a conversation or does not.

No charm offensive. No personality override. Just what your profiles say about you.

The quality of your digital presence has a direct and outsized effect on remote job outcomes.

The Profiles That Actually Matter

Not every platform deserves equal attention. Here is the stack worth building and maintaining.

Yes, you still need it. Yes, it is imperfect for developers. But most hiring managers will look for you there, and if they find nothing or find something outdated, that is a weak signal.

What actually matters on LinkedIn for remote developer roles:

Keep the headline specific. "Full-Stack Developer, Node.js and React" is better than "Software Engineer." Be the search result someone is actually running.

Write a summary that sounds like a person wrote it. Not a list of buzzwords. Two or three sentences about what you build, what you are good at, and what kind of work you are looking for. That is it.

List your side projects and products, not just your jobs. Remote employers care about what you build independently. A side project with users is a stronger signal than a job title alone.

Set your location to "Remote" or mark yourself as open to remote roles. This is basic and frequently skipped.

GitHub

GitHub is the developer's work record, and for remote roles it is often the second thing someone looks at after LinkedIn.

What remote employers look for: activity. Not necessarily high commit counts, but a profile that shows someone who codes regularly. A contribution graph dark for two years suggests someone who may not be building much.

Your pinned repositories are prime real estate. Pin your best work, not your oldest work. Write proper readmes. A repo with no readme is a door with no sign.

Contributions to other people's projects matter too. It shows you can collaborate in codebases you did not build, which is exactly what remote work requires.

Personal Portfolio

The live URL you can send to anyone.

For remote jobs specifically, the portfolio does one job above everything else: it proves you can finish things. A live product that actually works is the simplest possible proof that you can take something from idea to deployed reality.

Three to five projects with live demos, brief writeups, and links to the code. That is all you need. A portfolio with three excellent well-explained projects beats one with twelve incomplete or undocumented ones every time.

Your Professional Builder Profile

Beyond the portfolio sits a layer that most developers do not have: a structured professional record showing what you have been actively building over time.

This is where platforms like forg.to become relevant for remote job seekers. A forg.to profile is not a static portfolio. It shows your products and projects with live milestones, development activity, verified metrics, and a running record of what you have shipped.

When a remote hiring manager wants to understand whether you are an active builder or a passive one, this kind of profile answers that question in a way a CV cannot. One link that says: here is everything I have built, in order, with real outcomes attached.

What Remote Employers Are Actually Looking For

The technical skills part is obvious. They want competence.

What most developers underestimate is how much remote employers screen for a specific set of non-technical signals alongside the technical ones.

Evidence of independent shipping.
Can you finish things without someone managing you? Your profiles should show projects that went from idea to deployed reality. Not just code sitting in a repo, but shipped products with real users.

Communication through writing.
Remote work is async by default. How you write in your profiles, your readmes, your project descriptions, your LinkedIn summary. All of this is a preview of how you will communicate on the job. Vague or sloppy writing in profiles suggests vague or sloppy async communication on the team.

Consistency over time.
A GitHub with consistent activity across two years is more compelling than a burst of commits last month. A forg.to profile showing a history of shipped projects over time tells the story of someone who builds reliably, not just occasionally. Reliability is exactly what remote employers are trying to assess without being able to watch you work.

Self-direction.
Side projects are the clearest signal here. A developer who builds things outside of work because they want to is a developer who does not need constant direction to be productive. That matters enormously in remote environments where nobody is watching.

The Communication Signal Hidden in Your Profiles

This one is underrated enough to deserve its own section.

Every word you write in your profiles is a writing sample.

Your GitHub readme. Your LinkedIn summary. Your portfolio project descriptions. Your bio anywhere online.

Remote hiring managers know that remote work lives and dies on written communication. Clear async writing, well-structured documentation, the ability to explain complex things to people who are not in the room with you.

When they read your profile, they are not just assessing your technical background. They are assessing how you think and how you communicate.

This means writing your profiles like a person with something interesting to say. Not a list of skills. Not corporate fluff. Short, clear, specific sentences about what you build and how you think.

"I build developer tools that make debugging less painful" is more interesting than "results-oriented software engineer with 5 years of experience in full-stack development."

The first sounds like a person. The second sounds like every other resume in the pile.

Making Your Profiles Work Together

The mistake most developers make is treating each profile as a separate silo.

LinkedIn points nowhere. GitHub has no bio. Portfolio has no links back. Everything exists in isolation.

The goal is for your digital presence to feel like a coherent professional identity rather than disconnected fragments.

Link everything together. Your GitHub bio should link to your portfolio. Your LinkedIn should link to your GitHub and portfolio. Your portfolio should link back to your GitHub and professional profile. Create a web, not islands.

Keep the narrative consistent. The story you tell about yourself should be roughly the same across platforms. Same specialisation, same emphasis on what you actually do, same tone. Inconsistency creates doubt.

Keep everything alive. An outdated profile is worse than no profile. If your personal site has not been touched in two years, update it or take it down. If your GitHub has been dark for months, start committing again. If your forg.to profile has no recent milestones, add something. Stale digital presence signals someone who has stopped building or stopped caring. Either way it is not the signal you want to send.

The India-Specific Reality

If you are a developer in India looking for remote roles at global companies, your profiles carry even more weight than they might elsewhere.

Remote hiring managers at US and European companies often have limited direct context for evaluating developers from markets they are less familiar with. Your profiles do the work of establishing credibility before the conversation starts.

This means: your GitHub needs to be active. Your portfolio needs live projects. Your LinkedIn summary needs to sound like someone who can communicate clearly in English. Your professional profile needs to show real outcomes.

The bar for digital presence is higher when you are compensating for the absence of in-person context. Use that as motivation to build each profile better than most candidates bother to.

The One Thing That Changes Everything

Most remote job applicants have adequate profiles.

Technically correct. Reasonably complete. Not embarrassing.

The developers who land the roles they actually want have profiles that do something more. They tell the story of someone who builds consistently, ships real things, communicates clearly, and is actively working on something right now.

Not "here is my experience." But "here is a person who is genuinely, actively building things and has been for years."

That story lives across your GitHub history, your portfolio, your professional profile on forg.to, and every line you write about your work anywhere online.

Build that story.

Then the profiles are just the places it lives.

Why Build-in-Public Became a Spam Problem

Kumar Kislay — Wed, 17 Jun 2026 07:44:39 +0000

Build-in-public started as a genuinely good idea.

Be transparent. Share your journey. Let people watch you build something from nothing. The openness creates accountability, builds audience, attracts early users who care about the product before it launches.

For a lot of builders, it worked exactly like that.

Then it became a content strategy.

What Happened to Build-in-Public

When enough people saw that building in public could attract an audience, the practice shifted.

Instead of genuine transparency, it became a formula.

Day 1: announce the idea.
Week 2: post an update.
Week 6: excited to share the launch.
Week 10: lessons from our first 100 users.
Week 20: we are shutting down, here is what I learned.

Every step packaged as content. Every milestone framed as a story. Every product update posted as if an audience was waiting.

The problem: most of the time, nobody was.

The Spam Problem

Platforms that reward product posting attract product posting.

Twitter filled up with "building X in public, follow along" threads. LinkedIn feeds drowned in announcements. Product Hunt posts disappear within hours because everyone is launching and nobody is genuinely discovering.

The build-in-public movement, at scale, created a specific kind of noise.

Everyone broadcasting. Not enough people actually listening.

The issue is structural. When a platform makes it easy to post about your product, people post about their products. When there is no filter between genuine contribution and self-promotion, the promotional content takes over.

The signal-to-noise ratio collapses.

This is how platforms die slowly. Not from lack of users, but from lack of reason to pay attention.

The Algorithm Is a Values Statement

Here is something that does not get said enough about social platforms.

The algorithm is not a neutral tool. It is a values statement.

Whatever the algorithm rewards, the community produces more of. Reward engagement bait, you get engagement bait. Reward product spam, you get product spam. Reward genuine insight, you get genuine insight.

This is the lever that determines what kind of community a platform becomes.

Most platforms get it wrong because they optimise for engagement above everything else. Engagement is not the same as value. A spammy product post can generate engagement. A genuine technical insight can go unread. If the algorithm cannot tell the difference, the platform degrades regardless of how good the intentions were at the start.

What Forg Changed and Why

Forg's early positioning was drifting toward build-in-public.

The problem became clear fast. If the platform rewarded product posting, Forg would become a place where builders spam their products at each other with nobody actually paying attention. A promotional feed with a professional skin on top.

That is not a professional network. That is a bulletin board.

So the feed algorithm changed.

Genuine content gets priority. Tech insights, honest learnings, opinions about building, things that are actually useful or interesting to other builders. This is what rises in the feed.

Product updates and launch posts have their place, but they reach people only after a builder has established real presence through genuine contribution. You build an audience by being worth following. Then your product posts land somewhere real.

The principle: earn reach by contributing value, not by promoting yourself.

Why This Is the Right Call

Professional networks are built on trust and signal.

LinkedIn's core problem is that it became a promotional platform. Everyone is announcing, celebrating, sharing milestones. The genuine signal is buried under noise. Nobody opens LinkedIn expecting to learn something.

The platforms that stay useful are the ones where signal-to-noise stays high. Where you can open the feed and reliably find something worth reading.

That requires an algorithm that actively protects signal. It requires making a deliberate choice that not all content gets equal reach, and what determines reach is whether the content contributes something genuine to the people reading it.

This is how professional reputation works in the real world.

The people in any field who actually get listened to are not the ones who shout loudest about their own work. They are the ones who consistently contribute insight others find useful. Their signal-to-noise ratio is high enough that when they do talk about their work, people pay attention.

A well-designed feed algorithm replicates that dynamic at scale.

What This Means for Builders

Practically, the shift means one thing.

Post like a professional, not like a marketer.

Share what you actually learned this week. Write about the technical decision you made and why it was harder than it looked. Post about the thing you built that did not work and what you figured out from it. Talk about the tools you use, the patterns you keep seeing, the things the industry is getting wrong.

Build the kind of presence that makes people want to follow you because you are genuinely worth following.

Then, when you launch something or hit a milestone, post about it. At that point it lands somewhere real because you have an audience that actually cares about what you do.

The shortcut of posting product updates into the void never worked. It just took a while for platforms to stop rewarding it.

The Bigger Picture

There is a version of professional networking for builders that is actually useful.

Not a broadcast channel. Not a launch board. Not a feed of people announcing things to nobody.

A network where genuine contribution earns real reach, where builders post things worth reading, and where the platform actively maintains the quality of what it surfaces.

That is what Forg is trying to build.

The feed algorithm is not a technical detail. It is the most important product decision a social platform makes.

Get it wrong and you build a spam board.

Get it right and you build a network people actually want to be part of.

A Guide to Making the Most Out of Forg

Kumar Kislay — Sun, 14 Jun 2026 13:34:59 +0000

For builders who want to actually grow here, not just exist.

Forg (Forg.to) - Professional Network Of Builders.

This is a space built specifically for people who are actively building things. Not a resume showcase. Not a follower count competition. A place where the work itself is the identity, and where sharing the real story of building something gets more respect than polished announcements.

This guide covers what actually works on Forg, what doesn't, and why the platform is built the way it is.

Start With a Profile That Actually Says Something

Your Forg profile is the first thing people see when they land on your page. Make it do some work.

Profile photo: Use a real photo of yourself. It sounds obvious, but it makes a bigger difference than most people expect. People engage more with humans than avatars.

Bio: Keep it short and honest. What are you building? What do you care about? One or two lines is enough. You don't need to fit your entire life story here.

Connect your accounts: Forg pulls in activity from GitHub, LeetCode, dev.to, Medium, YouTube, and Dribbble. Link what's relevant to you. This is important: your Forg profile becomes a live snapshot of what you're actually doing, not a static resume. The more you link, the more your profile tells the real story of your work.

Add your product: If you're building something, add it. Even if it's early, even if it's rough. Forg's Launchpad is designed for exactly this: getting eyes on products that are actively being worked on.

A quick gut-check before you publish your profile: If a stranger landed on this, would they know who you are and what you're about in under 10 seconds?

How the Feed Works (And Why It's Built This Way)

Forg's feed is not chronological. It's a ranking system, and understanding it will save you a lot of frustration.

Two types of content, two different rules

Normal posts (thoughts, learnings, opinions, stories) get ranked on quality and engagement. Fresh content from newer builders gets a discovery boost. If you write something genuinely good, the feed will push it out even if you're new.

Product update posts work differently.

The Discovery Tax

If someone has never interacted with your product, your product update post is significantly reduced in their feed. This is called the Discovery Tax.

Here's why it exists: imagine scrolling and seeing "We just shipped our new AI widget v2.3!" You have zero context on this product. You don't know what it does, who built it, or why you should care. You scroll past. And that product just wasted a distribution slot on someone who was never going to engage anyway.

The Discovery Tax routes product updates to audiences that are actually relevant: people who've viewed your product, visited it, followed you, or upvoted it. Your updates reach the right people instead of bouncing off strangers who have no context.

This isn't a punishment. It's the feed protecting your posts from landing in the wrong place.

Upvotes are your distribution unlock

When someone upvotes your product, they're opting in to your journey. From that point on, your product updates reach them without penalty.

Think of every upvote as a subscriber to your update feed. The more upvotes you accumulate, the wider your updates reach. That's the compounding effect worth actually thinking about.

What to Post (And How to Post It)

Share your knowledge

The highest-leverage content on Forg is knowledge posts. Things you've figured out, frameworks you've been exploring, mistakes you made and what you learned from them.

These posts earn followers who stick around. They build a reputation for being someone worth paying attention to. And unlike product updates, they don't expire. A genuinely useful post stays in the feed for a while.

Document the process, not just the outcomes

"We just shipped dark mode" is fine.

"Here's what I got completely wrong trying to build our auth system, and what I'd do differently" is three times more interesting, for you and for the people reading it.

Forg rewards authenticity. Real posts with genuine engagement consistently outrank polished announcements that nobody interacts with. Share the actual experience of building, not just the press release version.

Give context when you share your product

If you're posting about your product, give people something to hold onto. What problem does it solve? What did you learn building this feature? What surprised you?

A link with no context is the easiest thing to scroll past. A link with a real story behind it gives people a reason to click.

Engage because you have something to say

Comment when you actually have something to add. Ask questions when you genuinely want to know. Reply when someone engages with your post.

The "interested" one-word comment culture from other platforms has no place here. If you're going to engage with someone's work, bring something real to the conversation.

Forg is a small community. People notice when engagement is genuine, and they remember it.

What to Avoid

Posting minor updates to strangers. Bug fixes and tiny improvements are worth logging, but they're not worth broadcasting to people who don't know your product yet. Save your updates for things that actually matter.

Sharing without context. If you post something (a product, a resource, a project) explain why you're sharing it. What should people look for? What makes it worth their time?

Chasing engagement for its own sake. Empty motivational posts, engagement-bait questions, hollow "what do you think?" prompts. These add noise and train people to skip your content. If you're sharing something, have a point.

Going quiet after someone engages with you. If someone comments on your post, reply. If someone asks a question, answer it. Those are real connections being built in public, and they compound over time.

The Cold Start: What to Focus on When You First Join

If you're new here, the most useful thing you can do in your first week is not post product updates.

Instead:

Finish your profile and link your accounts
Add your product to Forg
Post something genuine: a thing you learned, a problem you're wrestling with, an opinion you can defend
Engage with posts from other builders you actually find interesting
Earn upvotes on your product from people who genuinely care about what you're building

Once you've built that foundation, your product updates will reach people who are already interested. Before it exists, they're mostly going to bounce.

The Short Version

Forg is built for builders who are in it for the real thing. Share what you know. Document your actual journey. Engage with intent.

The platform is designed to route your content to the right people. The more you put into it (real posts, real engagement, a real presence) the more the feed works in your favour.

Happy building.

The Benefits of Building In Public

Kumar Kislay — Sun, 14 Jun 2026 10:18:41 +0000

There is a version of building that most developers default to.

Work quietly. Ship when ready. Tell people when it is done.

It feels professional. Disciplined. Like you are protecting your work until it is worthy of being seen.

The problem: most things never get "ready." And most developers who build in silence spend far longer than they need to before finding out if anyone wants what they are making.

Building in public is the opposite of that.

What Building In Public Actually Means

Building in public means sharing your process as you build, not just the outcome when you are done.

Progress updates. Failures. Decisions. Milestones. The messy in-between parts of making something from nothing.

Not polished blog posts written retrospectively. Not launch announcements. The real-time feed of what you are actually doing and thinking as you do it.

It sounds uncomfortable. For most developers it is, at first.

But the people who do it consistently report the same thing: they build faster, build better, and end up with more opportunities than they did when they worked in silence.

Here is why.

Accountability That Actually Works

Telling people you are building something is one of the most effective productivity tools that exists.

Not because of social pressure exactly. Because the act of committing publicly changes how you relate to the work.

When you post "shipping this feature by Friday," you have made Friday real in a way it was not before. When you share a weekly progress update, you are implicitly promising next week's update. When you post a milestone, you are establishing a baseline you will want to exceed.

None of this requires a large audience. Even ten people following your progress creates enough accountability to move faster.

The developer who builds in silence only answers to themselves when they slip a deadline. The one who builds publicly has made the deadline visible.

Visibility creates accountability. Accountability accelerates shipping.

The Feedback Loop You Did Not Know You Needed

Here is the most common way an indie developer wastes six months.

They have an idea. They build the full thing in private. They launch. Nobody wants it.

Wrong assumptions about the problem. Wrong solution. Wrong audience. And because they built in silence, they did not find out until they had already invested everything.

Building in public compresses this feedback loop dramatically.

You share what you are building early. You describe the problem you are solving. You show rough demos.

And the internet tells you immediately whether any of it resonates.

Someone says "I have this exact problem." Someone says "how is this different from X?" Someone says "I would pay for this but only if it did Y."

All of that is information you would otherwise wait until launch day to get. When it is too expensive to use.

Building in public turns your audience into your research department before you ship.

The Audience Problem, Solved Backwards

Most developers launch products with no audience.

They build in private, put up a landing page, share a link, and wait for users who never come.

Building in public solves this backwards, which is the only way it actually works.

By the time you launch, the people following your build are already invested. They have watched the problem, watched the solution take shape, watched the progress week by week. When you launch, they are not discovering you for the first time. They are seeing the end of a story they have been following.

That is a completely different kind of launch.

You do not announce a product to strangers. You ship to people who were already waiting.

The Serendipity Factor

This is the benefit that is hardest to plan for and the one most often mentioned by people who have built in public for a while.

Unexpected things happen when you are visible.

Someone who saw a progress update six months ago reaches out with a collaboration. A company finds your work and offers a contract. A developer who used something you built and mentioned publicly wants to contribute. An investor who had been watching your posts reaches out after a milestone.

None of these are things you can manufacture.

All of them require that your work was visible in the first place.

Building in public is not a strategy for any specific outcome. It is a strategy for creating the conditions where unexpected good things can happen.

The surface area for luck expands when people can see what you are doing.

It Makes You Better at Your Craft

Teaching forces understanding in a way that building alone does not.

When you explain a technical decision publicly, you have to know why you made it well enough to articulate it. Fuzzy thinking that would survive privately becomes obviously fuzzy the moment you try to write it down.

This is one of the less-discussed benefits of building in public.

The developer who writes about their architectural decisions is forced to have cleaner architectural thinking than the one who never explains their reasoning to anyone.

Writing about what you are building, sharing the problems you are solving, explaining the tradeoffs you are navigating. All of this does double duty.

You are building an audience and becoming a sharper developer at the same time.

The Loneliness Problem

Building something independently is isolating.

Especially in the early stages, when there is no team, no users, no external validation that what you are doing matters or will eventually work.

Building in public does not fully solve this but it meaningfully helps.

The people who follow your journey become a loose community of people who care about what you are building. They celebrate milestones. They commiserate when things break. They ask questions that make the work feel visible and real.

That is not nothing.

Solo builders who go completely dark often quit not because the product failed but because they ran out of the energy that comes from knowing the work matters to someone.

Visibility is not vanity. Sometimes it is what keeps you building.

The Professional Record Layer

Here is a distinction worth making.

Building in public on Twitter is real-time and ephemeral. Posts disappear into the feed. Your audience grows but there is no permanent, structured record of what you built and when.

This is where a professional profile becomes important alongside your public building practice.

The posts are the process. The professional record is the proof.

Platforms like forg.to are where the outcomes of building in public live permanently. When you hit a milestone it gets documented on your profile. When you launch a product it becomes part of your builder record. When you accumulate months of shipped work it forms a structured professional identity that a social feed cannot provide on its own.

Building in public is a habit. Your forg.to profile is what that habit produces over time.

Both matter. They do different jobs.

The Trust Compound

Transparency builds trust faster than any marketing can.

When people have watched you struggle with a problem, make a decision, ship a solution, and report honestly on how it went, they trust your judgment in a way that a landing page cannot manufacture.

This trust compounds slowly. You will not notice it for the first few months.

But at some point you will find that when you share an opinion, people treat it as informed. When you recommend a tool, people actually use it. When you ask for feedback, people take time to give it.

This is the reputation that builds when you are consistently transparent about your work over time.

It cannot be bought or shortcut. It can only be accumulated by showing your work honestly and consistently.

What Building In Public Is Not

A few things worth clearing up.

It is not oversharing. You do not need to post your emotional state, your doubts, your imposter syndrome spirals. Share the work and the decisions. Not the diary.

It is not marketing. If every post is a pitch for your product, people stop reading. The value is in the process, not the product pages.

It is not building for followers. The audience is a byproduct of genuine sharing, not the goal. Optimising for follower count makes the content worse and the practice unsustainable.

It is not required to be daily. Some builders share daily. Others weekly. The frequency matters less than the consistency and the authenticity of what you share.

How to Start

You do not need an audience to start.

Pick something you are currently building. Write one honest post about where you are with it right now. What you are trying to do. What is hard about it. What you decided this week.

Share it somewhere public. Twitter, a developer community, a blog, a profile update on forg.to.

Then do it again when something meaningful happens.

That is the whole practice.

The audience, the accountability, the feedback loops, the serendipity, all of it follows from the simple act of making your work consistently visible over time.

You have been building anyway.

The only question is whether anyone gets to see it.

How to Document Your Professional Developer Journey

Kumar Kislay — Fri, 12 Jun 2026 12:55:09 +0000

Most developers have this problem.

They build for years. They ship things, break things, figure things out, grow. And then when someone asks "what have you been working on," they struggle to answer.

Not because nothing happened. Because none of it was written down.

The work existed. The growth was real. But there is no trail.

This is what documenting your developer journey actually solves.

What Documenting Actually Means

First, let us clear something up.

Documenting your developer journey is not the same as becoming a content creator.

You do not need a YouTube channel. You do not need to tweet ten times a day. You do not need a newsletter with a catchy name or a personal brand strategy.

Documenting is simpler and more professional than all of that.

It means leaving a record of the meaningful moments in your work. The things you shipped. The milestones you hit. The decisions that turned out to matter. The failures that taught you something real.

That record is not for an audience. It is for anyone who ever needs to understand what kind of developer you are. Hiring managers, collaborators, investors, clients, future you.

You are not building a following. You are building a file.

Why Most Developers Skip It

It feels like extra work.

You are already building. Documenting on top of building feels like doing the same job twice.

And in the short term, that is kind of true.

Writing a post about a milestone takes 20 minutes you could spend shipping. Updating your professional profile when you launch something takes effort with no immediate return.

The problem is the long game.

Two years from now, you will have no record of what you built in this period. The products, the problems, the growth, the failures, the technical decisions. All of it will live only in your memory, and memory is not a professional record.

The work you do not document does not count professionally. Not because it did not happen. Because nobody can see that it happened.

What Is Actually Worth Documenting

Not everything. That is the first thing to get right.

Documenting every commit, every bug fix, every small decision is how you burn out and produce content nobody reads.

The meaningful signals worth capturing:

Product milestones
First user. First 100 users. First paying customer. First $100 in revenue. First $1,000. These are real, verifiable moments that tell a story about your trajectory as a builder.

Launches
Any time you ship something to the world. Even if it is small. Even if ten people see it. A documented launch is a timestamped proof point that you shipped.

Failures and pivots
The product you killed after three months. The feature nobody used. The technical decision that turned out to be wrong. These are not embarrassing. They are evidence that you are building real things, because real things fail in interesting ways.

Technical decisions that mattered
Not every architectural choice. But the ones where you picked a direction, lived with the consequences, and learned something. These are the entries that make you look like someone who thinks, not just someone who codes.

Side projects with outcomes
The tool you built for yourself that turned out to be useful to others. The open source release that got traction. The weekend project that became something more.

Open source contributions
Repos you created, contributed to meaningfully, or built things on top of. The parts of your work that exist publicly and can be verified by anyone.

The Three People You Are Documenting For

When you document your developer journey, you have three audiences. Understanding them changes what you write and how you write it.

Future you.
This is the most underrated audience. Two years from now you will want to know what you were building, what you were thinking, what worked and what did not. A documented journey is a retrospective you can actually run.

Anyone evaluating you.
Hiring managers, clients, collaborators, investors. They want to know: can this person actually build? Is there a track record? A documented journey answers that without you having to pitch yourself. The record speaks.

The internet.
The searchable, indexable trail of your work that shows up when someone Googles your name or finds your profile. You are not writing for this audience actively, but the documentation has to be findable.

Forg.to sits at the intersection of the second and third audiences. It is where your documented professional record lives publicly, structured as a professional profile rather than a blog, so when someone lands on it they immediately understand your trajectory as a builder.

The Build Log: The Most Underrated Format

Most developers either go too big (full blog post, long-form case study) or too small (a tweet, a commit message).

The build log sits in the middle and it is the most practical format for consistent documentation.

A build log entry is short. Three to five paragraphs.

What you built or worked on. What the hard part was. What you decided. What happened next.

That is it.

It does not need to be polished. It does not need a catchy headline or an introduction that explains what you are about to explain.

It just needs to be written and published.

Over time, a build log becomes one of the most compelling professional documents you can have. It shows consistent output, real thinking, and a developer who is always building something.

Where Your Documentation Should Live

Different formats belong in different places, and spreading documentation across five platforms with no central record is how things get lost.

GitHub: Code, commits, open source contributions. The raw evidence of technical output. Non-negotiable, but limited in scope.

A personal blog or dev blog: Long-form writing. Technical deep-dives, project post-mortems, things you learned that took weeks to figure out. Evergreen content that compounds in search over time.

Twitter or a public feed: Real-time updates. What you are building today, quick thoughts, launch announcements. High frequency, low permanence.

A professional profile: The central record. Products you have built, milestones you have hit, verified metrics, ongoing work. This is what pulls it all together into something that reads as a professional identity, not just a collection of posts scattered across platforms.

This is where forg.to is useful in a way that a blog or social profile is not. The structure is built for builders specifically. A product launch sits next to a milestone sits next to a project update, all attached to your professional identity. Not scattered. Not buried under old posts. One coherent record.

How Often to Document

Not daily. Not weekly on a fixed schedule.

Document at meaningful moments.

You launched something: document it.
You hit a milestone: document it.
You made a significant technical decision: document it.
Something failed in an interesting way: document it.
You learned something that took weeks to figure out: document it.

If you are actively building, this probably means documenting something every two to four weeks naturally. You do not need to manufacture content. The work generates it.

The discipline is not sitting down to write on a schedule. The discipline is noticing when a meaningful moment happens and capturing it before it disappears.

What Not to Document

The oversharing trap.

Some developers document every feeling, every struggle, every "I almost quit today" post. This is not a professional record. It is a diary. There is nothing wrong with a diary but it is not the same thing.

Avoid:

Daily progress updates with no actual progress to show
Emotional posts about burnout with no professional signal
"Day 47 of my coding journey" content with no product or outcome attached
Documenting the experience of learning without documenting what the learning produced

The distinction is simple: document outcomes and decisions. Not the experience of having them.

A Note on Showing Your Thinking, Not Just Your Shipping

There is one exception to the "outcomes only" rule.

When you are working through a genuinely hard problem and the reasoning matters, write it down while you are in it.

The architectural decision you are debating. The two approaches you are weighing. The tradeoffs that are not obvious.

Write a short post working through it publicly.

This kind of documentation is valuable for two reasons.

First, writing it forces you to think more clearly. The act of explaining a decision to an imaginary reader exposes the weak parts of your reasoning in a way that just thinking does not.

Second, it is rare. Most developers only document outcomes. The ones who document their thinking process in real time stand out because it is visible evidence of how they approach hard problems.

That is a different and more interesting signal than "I shipped a thing."

How to Start If You Have Nothing

Pick the last meaningful thing you shipped or built.

Write 300 words about it. What it was. What was interesting about building it. What happened after you shipped it.

Put it somewhere public. A GitHub readme, a blog post, a personal site, a profile update on forg.to.

That is your starting point.

Now do the same thing the next time something meaningful happens. Then again after that.

You do not need to go back and document everything you have ever built. You cannot. But you can start the habit today and let it compound from here.

The Record That Outlasts Every Job

Jobs end. Companies fold. Projects get deprecated.

A documented professional journey does not disappear when any of those things happen.

The record of what you built, what you shipped, what you figured out, what you failed at and tried again. That is yours permanently.

The developer who has five years of documented output is in a completely different position to the developer who has five years of undocumented work.

They may have built the same things.

But only one of them can prove it.

Document the work. It is the only version of your career that does not expire.

What Is Proof of Work for Programmers?

Kumar Kislay — Thu, 11 Jun 2026 10:30:00 +0000

In crypto, proof of work is a consensus mechanism. You do real computational work to validate a transaction. The work itself is the evidence. It cannot be faked.

The developer world borrowed the phrase for something similar.

Proof of work for a developer is everything that proves you can actually build things. Not the claim that you can. The receipts.

Why This Even Matters

Five years ago, saying "I'm a developer" meant something fairly specific.

Today everyone is a developer. Bootcamp graduates, vibe coders, people who have completed three courses and have a LinkedIn that says "Software Engineer." The supply of people claiming to be developers has exploded.

The signal has gotten noisy.

In that environment, what you have actually shipped becomes everything. Not your job title. Not your GitHub profile picture. Not the frameworks listed on your resume.

The question the market is increasingly asking: where is your proof?

What Counts as Proof of Work

Not everything counts equally.

A live product with real users is stronger proof than a GitHub repo with a readme.
A GitHub repo with real commits and history is stronger proof than "built X" on a resume.
Revenue is stronger proof than user count.
User count is stronger proof than downloads.
Downloads are stronger proof than stars.

The hierarchy roughly goes: existence beats description. Usage beats existence. Revenue beats usage.

Weak proof of work looks like:

"I built a full-stack app" with no link attached
A GitHub repo last updated two years ago
A to-do app tutorial project in a portfolio
Certificates from online courses

Strong proof of work looks like:

A live URL anyone can visit right now
An open source repo with real contributors or real usage
A product generating actual revenue, however small
A startup with customers, even if it is ten people
Documented milestones: first user, first paying customer, 100 stars, 1,000 monthly active users

The strongest proof of work is something that exists independently of you and keeps running.

The Difference Between Proof of Work and a Portfolio

These are related but not the same thing.

A portfolio is a presentation layer. You curate it, write the copy, tell the story about your work.

Proof of work is the underlying reality the portfolio points to. The live product. The repo with three years of commits. The SaaS that made $500 last month.

You can have a beautiful portfolio with weak proof of work underneath. That is a nice website with nothing behind it.

You can have strong proof of work with almost no portfolio at all. That is the developer with a dozen shipped products and zero personal branding, who still gets inbound because the work speaks.

Ideally you have both. Strong underlying proof, and a clear way for people to find and understand it.

GitHub Is Proof of Work. But It Has Limits.

GitHub is the most obvious home for developer proof of work.

Real commit history over years. Open source contributions. Stars on a repo other people built on top of. Pull requests merged into projects you did not create. These are all legitimate, hard-to-fake signals.

But GitHub only captures code.

If you are a founder who spent six months building a product, acquiring users, and hitting your first $1,000 MRR, almost none of that shows up on GitHub.

If you built something, launched it, got real feedback, iterated, and grew it, the most interesting part of that story is invisible in your commit history.

GitHub is proof of code work.

Developers are doing a lot more than writing code.

The Verification Problem

Here is the thing about proof of work that makes it genuinely different from a resume.

A resume is entirely self-reported. You wrote it. Nobody verified it.

Proof of work is verified by reality.

A live product verifies itself. Either it exists or it does not.

Real users verify themselves. Either people are using it or they are not.

Revenue verifies itself. The money either moved or it did not.

This is why proof of work carries so much more weight than credentials. Credentials can be inflated, exaggerated, or fabricated. Proof of work is anchored to things that exist in the world independently.

When someone looks at a profile on forg.to showing verified user counts, real revenue, and documented milestones on a product, they are not taking the builder's word for it. The numbers are tied to real outcomes. That is fundamentally different from "results-driven professional with 7 years of experience."

The Compounding Nature of Proof of Work

One shipped product is a data point.

Two shipped products is a pattern starting to form.

Five shipped products over three years is a track record.

A track record is worth more than any single credential because it answers the question that actually matters: does this person consistently build and ship things, or did they get lucky once?

This is why documenting ongoing work matters, not just final outcomes.

The product you launched last month. The open source tool you shipped last week. The milestone you hit yesterday. Each is a timestamped data point that, over time, builds a picture of someone who ships consistently.

Platforms like forg.to are built around exactly this idea. Your profile is not a static snapshot of past accomplishments. It is a living record that updates as you work, so the pattern of consistent output becomes visible over time. Not just what you shipped, but that you keep shipping.

What Strong Proof of Work Looks Like in Practice

A few examples of what this looks like when done well:

The indie hacker has three products publicly documented. One failed and they wrote about why. One is making $300 a month. One is growing. The failure write-up is actually proof of work because it shows they shipped something real enough to fail in a meaningful way.

The open source developer has one repo with 2,000 stars, real issues being filed, real pull requests from strangers who found it useful enough to contribute. Social proof baked directly into the work.

The early-career developer has no job history. But three GitHub repos with consistent commit history, a live side project with 50 users, and a documented build log showing what they tried, what broke, and what they learned. More compelling than most senior resumes.

The founder-developer has a product with paying customers. Even $100 MRR. Even ten users. Something that exists in the world that people chose to use. That level of proof is almost impossible to fake.

How to Start Building a Proof of Work Record

If you are starting from zero, the answer is not "build something impressive."

The answer is: build something and document it publicly.

Small is fine. Incomplete is fine. A project that only ten people ever use is fine.

What matters is that it exists, it is accessible, and there is a record of you having built it.

Some starting points:

Ship something and put it at a real URL
Write a short build log or post-mortem for each project
Keep your GitHub active with real work, not just tutorials
Post milestones when you hit them, even small ones
Track basic metrics on your projects and make them visible

Over time these accumulate into something substantial. A forg.to profile, a GitHub history, a personal site, a trail of documented work across the internet. All of it becomes evidence that you are a person who builds things and keeps building them.

That is your proof of work.

The Bigger Point

The best developers and builders in the world are not known because of where they went to school or what companies hired them.

They are known because of what they have shipped.

That has always been true. The difference now is that the infrastructure to document and share that proof publicly has never been more accessible.

You can deploy for free. Host for free. Build in public for free. Track and share your metrics, your milestones, your progress, for free.

The only thing standing between a developer and a strong proof of work record is not documenting the work.

Build things. Document them. Let the receipts speak for themselves.

Why Portfolios Matter for a Developer

Kumar Kislay — Wed, 10 Jun 2026 12:28:36 +0000

Imagine two developers applying for the same role.

Same skills on paper. Same years of experience. Same stack.

One sends a PDF resume. Clean, formatted, two pages.

The other sends a link.

The link goes to a handful of real projects. Live demos. GitHub repos. A short writeup on what problem each one solves and how they built it.

Who gets the call?

You already know the answer.

A Resume Is Just a Claim

Anyone can write "proficient in React" on a resume.

Anyone can list "built scalable backend systems" under a job they held three years ago.

Resumes are self-reported documents. There is no verification. No proof. Just words on a page that a recruiter skims for seven seconds before deciding if it goes in the yes pile or the no pile.

A portfolio is different.

A portfolio says: here is the thing I built. Here is how it works. Go try it yourself.

That is not a claim. That is evidence.

Why This Matters More for Developers Than Almost Anyone Else

Doctors cannot practice on the internet.

Lawyers cannot litigate publicly.

Accountants cannot share their clients' books.

But developers can literally show their work.

You can deploy a project for free. Put the code on GitHub. Write about what you built and why. Share a live demo anyone in the world can click.

Most professions would kill for that ability.

Developers have it and still send plain PDF resumes.

The Fresh Graduate Problem

Here is where it really matters.

You just graduated. Zero professional experience. Maybe an internship. Maybe not even that.

Your resume is almost empty.

But your laptop has three side projects you built over the last year. One is being used by real people. One has 200 GitHub stars. One you built in a weekend just to solve your own problem.

Without a portfolio, none of that exists professionally.

With a portfolio, you walk into interviews with more proof of ability than candidates who have been employed for two years but never built anything outside their job.

The portfolio is the equalizer.

What Actually Goes in a Good Developer Portfolio

Not a to-do app.

Sorry, but nobody is impressed by a to-do app. Every tutorial ends with a to-do app. It says "I completed a course." That is not nothing, but it is not a portfolio piece either.

What actually impresses people:

A real problem you solved.
Even if it is small. Even if it is just for yourself. "I was annoyed that X did not exist so I built it" is a story. That is interesting. That shows initiative.

A project with real users.
Ten real users is worth a hundred fake ones. If something you built is being used by actual humans who chose to use it, that is genuinely impressive.

A project that shows range.
Not five CRUD apps with different color themes. One project that shows you can think through a problem, architect a solution, build the thing, and ship it.

A project you can talk about.
The worst portfolio moment is when someone asks "walk me through this" and you go blank because you copy-pasted most of it from a tutorial. Build things you understand deeply enough to explain.

Show the Work, Not Just the Code

This is the part most developers skip.

A GitHub link is not a portfolio.

A GitHub link with no readme, commits that say "update", and code untouched for two years is actively worse than nothing. It signals you do not care.

What actually works: write two or three paragraphs about each project.

What was the problem? What was hard about building it? What would you do differently? What did you learn?

Not an essay. Just enough context that someone reading it understands the thought behind the work.

Hiring managers and clients are not reading your code. They are reading your reasoning.

For Freelancers, a Portfolio Is Your Pipeline

If you work for yourself, your portfolio is your sales page.

Every project you ship and document publicly is a future client finding you through Google, through a directory, through a recommendation.

Freelancers with strong portfolios do not chase clients.

Clients find them, reference a specific project, and say "I want something like this."

That is the best possible position to be in. You are not selling. You are selecting.

Getting there requires one thing: documenting your work properly and making it findable.

For Indie Hackers and Founders, a Portfolio Is Credibility

You are building products independently. No company name behind you. No funding announcement. Just you and what you have shipped.

In that context, your track record is everything.

When someone is deciding whether to use your product, collaborate with you, or invest time in your project, they are evaluating you. Not the product. You.

They want to know: has this person shipped before? Do they follow through? Can they actually build?

A documented history of what you have built answers all of those questions before the first conversation even starts.

This is exactly why platforms like forg.to exist alongside static portfolio sites. It gives builders a living profile where products, milestones, and ongoing work stay updated over time. Your professional record is never stale because it moves with what you are building.

Common Portfolio Mistakes

Listing every tiny project you have ever touched.
Quality over quantity. Three strong well-documented projects beat fifteen half-finished ones. Curate ruthlessly.

No context or writeup on anything.
Links without explanation are just links. Nobody knows what they are clicking into or why they should care.

A portfolio that looks like it was built in 2014.
Your portfolio is itself a demonstration of your taste and attention to detail. Design does not have to be fancy. Clean is enough. But neglected is a signal.

Only showing finished, polished things.
Work in progress is fine. Showing something you are actively building is compelling. It says you are alive and shipping, not maintaining a museum of old projects.

Never updating it.
Your last project was two years ago. What have you been doing? Update it. Even small things count. A portfolio that never changes starts to feel abandoned.

GitHub Is Not a Portfolio (But It Matters)

GitHub is where your code lives.

A portfolio is where your story lives.

They are not the same thing and you need both.

Your GitHub shows activity, consistency, and open source engagement. A recruiter or collaborator will absolutely look at it. But it does not communicate the narrative of what you have built, why you built it, or what you are capable of beyond writing code.

Your portfolio provides the context that GitHub cannot.

Link your GitHub from your portfolio. Do not use GitHub as a replacement for it.

Where to Start if You Have Nothing

You do not need a beautiful website immediately.

Start here:

Pick one project you are proud of. Write 300 words about it: what it does, why you built it, what was technically interesting, what you would change. Add a GitHub link and a live demo if it exists.

That is already more than most developers have.

Then add a second. Then a third.

Over time you can put these on a personal site, a professional profile like forg.to, or any platform that lets you document your work publicly and keep it updated.

The medium matters less than the habit of documenting.

The Compounding Effect

Here is the thing nobody tells you about portfolios.

The benefit is not immediate.

The first project you document gets seen by almost nobody. The second, same. But by the time you have six well-documented projects, a history of shipping, and a profile showing consistent output over two or three years, you are in a completely different position.

Opportunities come from people who were already watching.

Clients reach out because they saw your work before. Job offers come in because a recruiter found a project from a year ago. Collaborators show up because they noticed a milestone you posted six months back.

None of this happens if you do not document.

All of it becomes possible when you do.

The Simplest Reason

At some point someone is going to Google you.

A recruiter. A potential client. A collaborator. An investor.

What are they going to find?

If the answer is nothing, or a LinkedIn profile that has not been touched since your last job change, that is a missed opportunity.

A portfolio is just proof that you exist professionally.

Build things. Document them. Put them somewhere people can find them.

Everything else follows.