Have you ever written down a great idea, only to forget about it a few days later? Or saved something important and struggled to find it when you needed it?

Taking notes is easy. Making them useful is the real challenge.

Whether you are studying, working on a project, or collecting ideas for something new, a good note taking habit can help you stay focused and get more done. You do not need a complicated system, either. A few simple habits can make a big difference.

1. Capture ideas as they come

Great ideas do not always show up when you have time to explore them. You might be working on a project, watching a tutorial, or thinking about something completely unrelated when an idea suddenly clicks.

Instead of hoping you will remember it later, write it down.

A quick sentence or a few keywords are enough to get started. You can add details when you have more time.

The goal is simple: spend less energy trying to remember everything and more time actually using what you learn.

2. Turn your notes into action

Writing down an idea is a good start, but what happens next?

Imagine you have a note containing ideas for a new website feature. You have explained how it should work and why you want to build it. Now you need to turn that idea into something real.

This is where connecting notes to tasks comes in handy.

Instead of keeping your ideas separate from your to do list, you can link a task directly to its related note in LogHue. This keeps the information behind your work connected to the action you need to take.

For example, you could write a note about a new feature, then create a task to build it and link the two together. When you return to the task, the relevant note is still connected to it.

This can be useful for personal projects, school assignments, research, and anything else where an idea needs to become actual work.

Not every note needs a task, of course. Sometimes you just want to save something useful for later.

3. Make finding your notes easier

There is nothing more frustrating than knowing you wrote something down but not being able to find it.

A little thought when naming your notes can save you time later. Give each note a title that describes its content, such as "JavaScript array methods" or "Preparing for my database exam."

This is especially useful in LogHue Notes, where you can search by note title. Using clear, specific titles helps you find the right note without having to guess which one contains the information you need.

It is a small habit that becomes more valuable as you create more notes.

4. Revisit your notes from time to time

You do not need to review every note every day. But taking a few minutes each week to look back at what you have collected can help you spot useful ideas and remember things you might otherwise forget.

You might find a solution to a problem you are currently facing, rediscover an idea worth exploring, or realize that something you learned a while ago is relevant to a new project.

Try asking yourself one question: Is there anything here I can use right now?

If the answer is yes, decide what to do with it. That might mean creating a task, applying what you learned, or simply keeping the information handy.

5. Find a tool that fits your workflow

You can take useful notes in a notebook, a text file, or a digital application. The best choice is one that fits naturally into the way you already work.

If you prefer digital notes, LogHue Notes is worth exploring.

You can create and manage notes, organize them within workspaces, share them through public links, and import or export workspaces. You can also link tasks to notes, keeping related information and work connected.

Whether you want to collect research, keep track of ideas, or support a larger project, it gives you a place to bring your notes and tasks together.

Explore LogHue Notes at https://loghue.com.

Final thoughts

Better note taking is not about writing down everything or creating a perfect system. It is about capturing information that matters and making it useful when the time comes.

Write down your ideas, connect them to tasks when needed, and revisit your notes when they can help you move forward.

Start with a few simple habits and build from there. Your notes should make your life easier, not give you another thing to manage.

Read the full article on Forg →

Eight development iterations, a rebuilt alert system, better agent orchestration, and a completely redesigned cyberpunk GitHub experience.

When I first wrote about Cobalt Cockpit, the project was approaching v0.5.2.

The idea was straightforward: I wanted more visibility and control over what Claude Code was doing while working on real software projects.

Not just a progress bar. I wanted to know which agents were working, what they were responsible for, why tasks were blocked, what had actually been verified, and whether Claude's claims of completion matched the available evidence.

At the time, Cockpit already had its HUD, Neural Flow, model telemetry, verification guards and Run Ledger.

Since then, I've pushed the project through eight more development iterations.

Cobalt Cockpit is now at v0.6.0, and the project has grown into something substantially more useful.

Here's what changed.

1. Better security and stronger verification

The first major improvement after v0.5.2 wasn't a flashy new interface.

It was tightening the security model.

v0.5.3 focused on authorization, task identity and verification integrity.

The distinction matters because not every action originating inside an AI coding environment should have the same authority as a command typed by the actual operator.

Sensitive Cockpit operations now require an authorized human origin. Project fingerprints account for repository identity, review consultations require the expected agent identity, and verification holds are harder to bypass through corrupted or stale state.

The principle is simple:

A coding agent reporting success is not the same thing as the system having evidence of success.

That principle now runs through much of Cockpit.

2. Cobalt Guard became a proper alert system

One of the biggest additions between v0.5.4 and v0.5.9 was the evolution of Cobalt Guard.

Originally, Guard could notify me when a run needed human attention.

But a single notification isn't particularly useful if I'm away from my desk.

So I started building around that problem.

Persistent alerts

v0.5.4 introduced optional reminders for unresolved conditions, with cooldowns, session budgets and acknowledgment controls.

An alert could repeat while the condition remained open, but it wouldn't repeat forever.

Acknowledging an incident stopped its reminders without pretending the underlying problem had been fixed.

Verified notification transport

v0.5.5 introduced something I consider particularly important: testing the notification channel itself.

Cockpit distinguishes between a notification being attempted, the host reporting that it was sent, and a person confirming that they actually observed the test.

I tested this on my own setup: Claude Code running remotely inside a Boat development environment, connected over SSH to Fedora KDE through WezTerm.

Initially, terminal bells worked.

Then I switched to the iTerm2-compatible notification channel and received readable desktop notifications, including the confirmation code.

I entered that code back into Cockpit, and it recorded my confirmation.

That was a satisfying milestone because the feature wasn't just passing mocked tests. I could actually see and hear it working across the remote connection.

Priorities and quiet hours

v0.5.6 added alert severity, configurable notification categories, persistent HUD warnings and timezone-aware quiet hours.

Normal blocked-task notifications can now be deferred while critical security conditions receive different treatment.

And because a terminal notification may itself trigger a bell, quiet hours needed to prevent notification calls rather than simply mute a separate sound effect.

I tested that behavior too, including a deferred notification arriving after the quiet-hours window ended.

3. An alert inbox that survives sessions

A desktop notification disappears.

An engineering issue doesn't necessarily disappear with it.

v0.5.7 introduced /cockpit alerts, a persistent inbox with incident identities, priorities, timestamps, notification states and individual acknowledgments.

v0.5.8 improved how that information survives concurrent sessions.

Instead of relying only on shared history snapshots, acknowledgments gained their own durable storage keys. That prevents a stale session from overwriting another session's acknowledgment under the tested host-storage behavior.

I also added a return digest so Cockpit can summarize outstanding recorded alerts when I return to a project.

Then v0.5.9 introduced record-only mode.

This is useful when I want observability without interruptions.

Cockpit can record blocked runs, security failures and other alert-worthy conditions without sending desktop notifications or playing sounds.

It also added a Since Last Look summary, tracking new occurrences by identity rather than relying on timestamps.

The notification history is bounded, project-scoped and designed to avoid storing arbitrary prompts or source-code contents.

There are still limitations to cross-session visibility and storage concurrency, and those are documented rather than hidden.

4. v0.6.0 brings the focus back to Mission Control

After several releases strengthening Cobalt Guard, I wanted the next milestone to improve Cockpit's original purpose: understanding and coordinating agent-driven development.

That's what v0.6.0 delivers.

Agent Inspector

The new /cockpit agents command provides a detailed view of the swarm.

I can inspect assigned tasks, agent tiers, ownership, dependencies, orchestration waves, capacity, last observed activity and verification status.

There's also a task-specific view:

/cockpit agents <task-id>

One detail I care about is reasoning effort.

Cockpit distinguishes between effort requested for an agent, effort set at launch, effort applied by the host when observable, and effort the engine actually reports.

If the information isn't available, it says so.

It doesn't invent measurements.

Blocker Intelligence

The inspector also explains why an assignment isn't progressing.

Maybe another task must finish first. Maybe two agents want to write to overlapping files. Maybe the agent pool has reached its capacity. Maybe an escalation is waiting for the commander.

Cockpit uses its existing admission rules to explain these states, rather than inventing a separate scheduling system.

The explanations are informational. They don't automatically override ownership or clear blocked work.

Verification Readiness

The other new command I'm particularly pleased with is:

/cockpit ready

It shows what's preventing a task from being declared DONE.

That can include incomplete milestones, failed or stale verification gates, unresolved Stop Guard holds, pending reviews or missing acceptance evidence.

Cockpit distinguishes checks observed through command results from results merely reported by an agent.

The command doesn't approve anything. It explains the existing completion rules.

This is the direction I want the project to keep moving in: less guessing about progress, more clarity about the actual state of the work.

5. Opus, Sonnet and Haiku working together

Cobalt Cockpit supports two orchestration profiles.

In OPUS_LED, Opus acts as the main coordinator, while Sonnet handles bounded engineering and reviews, and Haiku handles lightweight scouting and utility tasks.

In SONNET_LED, Sonnet leads everyday development, while Opus is available for admitted architecture and review consultations.

The main session's reasoning effort remains under the operator's control. Subagent effort can be selected based on the task.

Cockpit manages assignment records, resource budgets, dependencies and ownership rules.

It doesn't promise that every available agent will be used, and it doesn't replace Claude Code's underlying model availability or permission controls.

For my more demanding engineering sessions, I currently prefer Opus as coordinator, Sonnet for implementation and Haiku for bounded reconnaissance.

The aim is effective delegation, not creating a swarm just to watch agents move around.

6. A complete cyberpunk README redesign

The other big update isn't a runtime feature at all.

I completely redesigned the Cobalt Cockpit GitHub README.

The old README contained plenty of technical information, but visually it looked much like any other developer repository.

I wanted the landing page to reflect what Cockpit actually feels like.

The new design includes a custom cyberpunk Mission Control banner, cobalt-blue visuals, light and dark variants, animated SVG elements, an illustrated module gallery and expandable documentation sections.

There's also a 44-second animated walkthrough showing the Cockpit interface and its workflow.

The demo uses scripted inputs against the real plugin's rendering and command interfaces in an offline test host. It's explicitly labeled as a synthetic demonstration, not footage of an autonomous production run.

The documentation has also been reorganized into dedicated guides, making the README easier to explore without discarding the detailed architecture, security and configuration information.

And everything is designed around GitHub's actual Markdown capabilities.

No fake web-app controls embedded into a README.

You can see the new look here:

https://github.com/echelong/cobalt-cockpit

7. What about testing?

For the v0.6.0 engineering milestone, the verification report recorded:

2,161 passing tests across 55 files, with zero failures.

The release also passed its local TypeScript, strict plugin validation, archive checks, public audit and secret-scanning gates.

GitHub CI and the Gitleaks workflow passed on the v0.6.0 implementation commit.

A new acceptance harness also ran two actual Claude Code host processes against disposable storage, completing ten checks without using model calls, credentials or the operator's real data.

Separate independent reviews examined the new features, security-sensitive changes and Directory compatibility refactor.

Some newer runtime behavior still needs human acceptance in live sessions. I'm keeping those results separate from automated verification.

That's intentional.

Passing tests matters, but I don't want a testing summary to imply that every possible runtime condition has been observed.

8. The Anthropic Plugin Directory

Cobalt Cockpit has also been submitted to the Anthropic Plugin Directory.

The Directory's validator previously flagged a capability-inspection issue involving how certain host API calls were structured.

v0.6.0 includes a refactor addressing that class of finding, along with expanded documentation of the plugin's capabilities and a local regression check.

Directory approval is not yet confirmed.

The repository remains publicly available on GitHub independently of that review.

What's next?

Cobalt Cockpit started as a way to see what Claude Code was doing.

It's gradually becoming a way to understand why work is progressing, why it's waiting, which agents are involved, and what evidence supports a completion claim.

There's still plenty to improve, especially around agent ergonomics, coordination, resource usage and making the HUD more actionable during complex development sessions.

But v0.6.0 feels like an important step.

I'm building this because I use AI coding agents on real projects, and I want the surrounding tooling to make them easier to supervise, not harder to understand.

If you're using Claude Code and care about observability, bounded delegation and verification, take a look.

Cobalt Cockpit is open source under MIT.

Repository and redesigned README:

https://github.com/echelong/cobalt-cockpit

I'm interested in feedback from other developers using multiple agents, particularly around what you wish you could see during a long-running coding session.

Read the full article on Forg →

Looking for a free screen recorder for Chrome with no watermark? Many screen recording tools offer free plans, but their restrictions can make it difficult to use them for everyday work. Some limit how many videos you can create, others restrict recording time, and some lock useful editing or export features behind paid subscriptions.

The right screen recorder should let you capture your screen, save your video without branding, and share or edit it without unnecessary friction.

Recordful is our recommendation for people who want free, local-first screen recording in Chrome without a watermark, a required sign-in, or an imposed time limit on local recordings. It supports screen and tab capture, microphone and system audio, live annotations, cursor-following zoom, and exports in MP4, WebM, and GIF formats.

This guide compares Recordful with Loom, Screencastify, Clipchamp, and Awesome Screenshot to help you choose the best free screen recorder for your workflow.

What to Look for in a Free Screen Recorder Without a Watermark

Before choosing a Chrome screen recording extension, check more than whether its free plan includes a watermark. The recording limits, export options, and privacy model can matter just as much.

These criteria help distinguish a genuinely useful free screen recorder from a restricted trial.

1. Recordful: Best for Free, Local Screen Recording in Chrome

Recordful is a Chrome extension designed for recording your screen and creating clearer, more polished videos. It is particularly useful for developers, SaaS founders, teachers, product marketers, and support teams.

You can install the extension, start a local recording, and export your video without creating an account.

What is included in Recordful Free?

No sign-in required

Start recording without registering for an account or entering payment details.

No watermark

Export your recordings without Recordful branding.

No imposed time limit on local recordings

Recordful's published Chrome Web Store listing states that local recordings have no time limit. Actual recording duration can still depend on available device storage, browser stability, and hardware resources.

Multiple recording sources

Capture a browser tab, window, or full screen. You can also record your camera, making it useful for demonstrations and instructional videos.

Microphone and system audio

Record narration alongside application or browser audio where supported. Push-to-talk controls can help you manage when your microphone is active.

Live annotations

Draw on the screen, add text and arrows, highlight clicks, and use visual emphasis to direct the viewer's attention.

Cursor-following zoom

Recordful includes automatic zoom that follows your cursor. This helps make interface interactions easier to see without requiring you to manually enlarge every detail during recording.

Built-in editing and export

Trim and crop recordings, make basic audio adjustments, and export videos in MP4 or WebM format. GIF export is also available for short demonstrations and bug reports.

Local-first storage

Recordings are stored locally until you choose to export or upload them. The Chrome Web Store privacy disclosure states that the developer has declared that it does not collect or use user data.

Open source

Recordful is distributed under the GPLv3 license, according to its project information.

Explore the Recordful Chrome extension to see its current features.

What does Recordful Pro add?

Recordful Pro is designed for people who need more than local recording. Its additional capabilities include cloud storage, shareable video links, advanced editing with zoom keyframes, and captions.

The important distinction is that you do not need Pro just to make local screen recordings without a watermark. The paid plan is intended for users who need cloud-based sharing and additional editing capabilities.

Visit Recordful Pro for current plan details.

Who should choose Recordful?

Recordful is a strong fit if you want to:

• Record software demos, tutorials, and bug reports.

• Capture your screen without creating an account.

• Export local recordings without a watermark.

• Annotate interactions and highlight important interface elements.

• Keep recordings on your device until you choose to share them.

• Create videos without relying on a separate editor for every basic adjustment.

Its main advantage is the combination of local recording, visual controls, and export flexibility in one Chrome extension.

2. Recordful vs. Other Free Screen Recorders

Recordful is not the only tool that offers free recording or watermark-free exports. The right alternative depends on whether you prioritize local files, hosted sharing, editing, or collaboration.

The comparison below uses the tools' published plan information. Features and limits can change, so check the linked official pages before making a final decision.

Official references: Loom Starter plan, Screencastify pricing, Clipchamp free-plan details, and Awesome Screenshot pricing.

Recordful vs. Loom

Loom focuses on asynchronous video communication. It is useful when you want to record a message and send a link that colleagues can open and comment on.

Its Starter plan has a five-minute recording limit and a maximum of 25 videos and screenshots. The paid plans provide additional capabilities, including the removal of Loom branding.

Choose Loom when hosted video messaging and collaboration are your primary needs. Choose Recordful when you want an account-free local recording workflow, more control over the exported file, and no imposed time limit on local recordings.

Recordful vs. Screencastify

Screencastify is a browser-based recorder that supports sharing and education-oriented workflows. Its current free plan allows up to 10 videos, with recordings of up to 30 minutes each.

Recordful is better suited to users whose priority is local recording without a sign-in requirement or watermark. Screencastify may be a better fit if its classroom and collaboration features match your needs.

Recordful vs. Clipchamp

Clipchamp is primarily a video editor with recording capabilities. Its free plan supports watermark-free exports up to 1080p, making it a legitimate option for users who want to assemble and edit videos.

Recordful offers a more direct workflow for capturing a screen in Chrome, annotating it, and exporting the result. Clipchamp is worth considering when you need a broader editing environment.

Recordful vs. Awesome Screenshot

Awesome Screenshot combines screen capture, annotation, and video recording. Its free plan allows unlimited local recordings of up to five minutes each, while cloud recording storage has a separate limit.

Recordful is the better fit for longer local recordings without an imposed recording time limit. Awesome Screenshot can be convenient for people who frequently switch between annotated screenshots and short recordings.

3. Which Free Screen Recorder Should You Choose?

The best free screen recorder depends on what you are trying to create.

Choose Recordful if you want a Chrome screen recorder without a watermark. It is suited to local recording, software demonstrations, tutorials, and bug reports, with annotation, cursor-following zoom, and multiple export formats.

Choose Loom if you primarily need hosted video messages. Its sharing and collaboration workflow is more important than unrestricted local recording.

Choose Screencastify if education and browser-based collaboration are central to your workflow. Review its current free recording limits before committing to it.

Choose Clipchamp if editing is your primary task. It supports watermark-free exports at up to 1080p on the free plan.

Choose Awesome Screenshot if you mainly need screenshots alongside short recordings. Its local recording time limit may be sufficient for quick demonstrations.

For someone who regularly records software workflows, product features, or technical problems, the ability to save longer local recordings without a watermark or mandatory account can make Recordful a practical everyday tool.

4. How to Record Your Screen in Chrome Without a Watermark

Getting started with Recordful is straightforward.

1. Install the Recordful Chrome extension.

2. Open the extension and select the recording source that you need.

3. Configure your microphone, system audio, and camera where applicable.

4. Start recording and use annotations or cursor emphasis to make important actions easy to follow.

5. Stop the recording, review the result, and make any necessary edits.

6. Export your video in a supported format, such as MP4 or WebM, or create a GIF when appropriate.

For a product demo or tutorial, it helps to plan the sequence of actions before recording. Keep the cursor movement deliberate, close unrelated windows, and pause briefly before important clicks. Those small changes can make the finished recording easier to follow without adding editing work.

Frequently Asked Questions

What is the best free screen recorder for Chrome with no watermark?

Recordful is a strong choice for users who want local Chrome screen recording without a watermark, account registration, or an imposed time limit on local recordings. It also includes annotations, cursor-following zoom, and several export formats.

Clipchamp is another option if your main requirement is editing and exporting videos without a watermark. Its free plan supports exports up to 1080p.

Is there a completely free screen recorder without a time limit?

Recordful's published Chrome Web Store listing states that local recordings have no time limit. You should still account for available storage, device performance, and browser stability. Its current free local workflow does not require a paid subscription to remove a recording time limit.

Can I record my Chrome tab with audio for free?

Yes. Recordful supports tab and desktop recording with system audio, along with microphone and camera capture. Audio availability can depend on the selected recording source, browser permissions, and operating system.

Can I record my screen without creating an account?

Yes. Recordful's free local recording workflow does not require sign-in. Account or workspace setup may be needed when using optional cloud services.

Can I export screen recordings as MP4, WebM, or GIF?

Recordful supports MP4 and WebM exports, along with GIF export. These formats are useful for different purposes: MP4 is widely compatible, WebM works well for web content, and GIFs can be useful for short looping demonstrations.

Are Recordful recordings uploaded to the cloud automatically?

Recordful uses local-first storage for local recordings. Its published listing states that recordings stay on your device unless you choose to share them. Cloud upload and sharing features are separate from the local recording workflow.

For confidential recordings, review the extension's permissions and privacy policy before use.

Is Recordful suitable for software tutorials and bug reports?

Yes. Recordful supports screen capture, annotation, cursor-following zoom, and common video export formats. These features help developers show a bug, demonstrate a fix, or explain a software workflow.

Final Verdict: A Free Chrome Screen Recorder Without a Watermark

You should not have to create an account, accept a watermark, or hit a short recording limit just to capture a software workflow.

Recordful offers a local-first alternative for people who want to record their screen in Chrome, annotate important actions, and export videos without a watermark. Its cursor-following zoom and built-in editing tools also make it useful for creating clearer product demonstrations, tutorials, and bug reports.

If local recording and export flexibility are your priorities, start with Recordful. If you need hosted collaboration or a full video editing environment, compare it with the alternatives above and choose the workflow that fits your needs.

Try Recordful for free in Chrome.

Read the full article on Forg →

A good screen recording should make every click easy to follow. But when you record a full desktop, menus, buttons, and important details can become difficult to see, especially on smaller screens.

Recordful is a free Chrome screen recorder that helps you capture, edit, and share clearer screen recordings. Record a browser tab, application window, selected area, full screen, or camera. Add annotations while recording, enhance your footage with automatic zoom and editing tools, and export your video or share it through the cloud with Recordful Pro.

Whether you create SaaS demos, product tutorials, software walkthroughs, online lessons, or customer support videos, Recordful brings screen recording and video editing into one workflow.

What Is Recordful?

Recordful is a Chrome extension for recording your screen and turning raw captures into polished videos.

Unlike a basic screen capture tool, Recordful combines recording controls, live annotations, camera layouts, audio editing, zoom effects, and video exports in one interface. Its automatic zoom feature helps viewers focus on the buttons, menus, and interface elements that matter.

Recordful also offers a free local recording workflow without a sign-in requirement or watermark. When you need cloud storage, shareable links, captions, and additional editing capabilities, Recordful Pro adds those features to your workflow.

1. Automatic Zoom That Makes Every Click Easier to See

The problem with most raw screen recordings is not the recording quality. It is the lack of visual focus.

A full-screen capture might show everything, but viewers can struggle to follow a small button, a settings menu, or a particular field in a complex dashboard. Editing every moment manually takes time, too.

Recordful makes zoom a central part of the editing experience.

How automatic zoom works

Record your screen as usual and move through your product naturally. Recordful can place zooms around your clicks so that important interactions become easier to see.

Each zoom can move smoothly toward an action, hold the viewer's attention, and return to a wider view when context is needed. You can adjust the generated zooms rather than rebuilding the entire sequence from scratch.

You can also customize the movement:

• Add manual zooms and choose how closely to zoom in.

• Make the zoom follow your cursor or target a specific point.

• Adjust perspective to create anything from a subtle zoom to a more dramatic camera movement.

• Customize the direction of the perspective effect.

• Transition directly between nearby zooms when pulling back would interrupt the flow.

The result is a screen recording that feels more deliberately directed, without requiring you to animate every movement manually.

Automatic zoom is particularly useful for software demonstrations, onboarding videos, feature announcements, and tutorials where viewers need to understand exactly what happened on screen.

2. A Screen Recorder and Video Editor in One Place

Recording is only the first step. You often need to remove mistakes, adjust framing, improve audio, or emphasize a particular action before sharing your video.

Recordful combines recording and editing so you can handle these tasks within the same workflow.

Record your screen, window, tab, or camera

Choose the source that matches your task. Record a browser tab, selected screen area, application window, full desktop, or camera-only video.

You can also capture microphone input and system audio together, with separate tracks available for adjusting their levels later.

Annotate while recording

Explain your actions as you work. Recordful supports live drawing, text, arrows, shapes, cursor highlighting, click effects, and spotlighting.

These tools help viewers follow instructions without having to guess where your cursor went or which part of the interface matters.

Create a polished camera layout

When you record your webcam alongside your screen, your camera footage does not have to remain in a fixed corner.

In the editor, you can reposition and resize the camera, select a circular or rectangular shape, adjust corners and shadows, mirror the image, and hide the camera when it is no longer needed.

You can also use separate tracks to control when your camera appears and adjust its size during zooms so that it does not cover important interface elements.

Edit video and audio independently

Recordful's editor provides separate tracks for video, camera footage, zooms, captions, sound, and music.

You can trim clips, adjust framing and padding, choose backgrounds, add corners and shadows, control audio levels, mute unwanted sounds, and add background music. Music ducking can lower the volume beneath your voice, then bring it back up during pauses.

Additional editing tools include playback speed controls and fade transitions to help smooth out cuts.

The goal is to give you useful editing controls without requiring you to learn a full professional video editing suite.

3. Free Screen Recording Without a Watermark

A screen recorder should let you get started without making you sign up for an account or upgrade before you can save your work.

Recordful's free recording workflow is designed around local capture and exports.

With Recordful Free, you can:

• Record your screen, browser tab, application window, selected area, or camera.

• Capture microphone and system audio.

• Pause and resume recording.

• Use live annotations and manual zoom controls.

• Use the available camera background and blur features.

• Trim and crop recordings and perform basic audio cleanup.

• Export videos in MP4 or WebM format, or create GIFs.

• Save recordings locally and use the available Google Drive export option.

Recordful also supports offline recording, with recordings saved to local browser storage. This helps when you are working with an unstable internet connection. Cloud uploads and sharing naturally require connectivity.

There are no recording-count limits or watermarks in the free offering described here.

Recordful is also open source under the GPLv3 license, allowing developers to inspect its source code and build it themselves.

For developers documenting bugs, teachers preparing lessons, founders creating quick demos, and support teams explaining fixes, the free version provides a practical way to capture and export screen recordings.

4. Recordful Pro for Cloud Sharing and Advanced Editing

Local recording works well when you need a video file. Sharing a recording with a team or customer often requires a different workflow.

Recordful Pro adds cloud capabilities for people who want to upload, organize, and share their recordings.

Share recordings through a link

Recordful Pro uploads recordings in the background. Its resumable upload workflow is designed to continue after interruptions, reducing the need to restart an entire upload.

Once your video is ready, you can share a link instead of exporting a large file and uploading it to another service.

You can keep recordings private to your workspace or enable a link that other people can open without creating an account.

Organize your recordings in one dashboard

Keep your recordings together rather than searching through folders full of similarly named video files.

Recordful Pro provides a central dashboard and shared workspace features for teams that need to manage and share recordings.

Generate captions and transcripts

Captions make recorded explanations easier to follow when viewers cannot use audio or prefer reading along.

Recordful Pro generates transcripts in ten languages, according to the product feature set described here. The editor lets you correct text and timing, customize caption fonts and colors, and highlight words as they are spoken.

Depending on your workflow, captions and transcripts can help viewers review tutorials, follow product demonstrations, and skim internal updates without watching every second of a video.

Recordful Pro pricing

The pricing described for Recordful Pro is:

• Monthly: $7.99 per month.

• Yearly: $59 per year, with a 14-day free trial.

The free option remains available for local recording and export. Pro is intended for users who need cloud storage, sharing, and premium editing capabilities.

Check the live pricing page before publishing or purchasing, since subscription prices and included features can change.

5. Built for Product Demos, Tutorials, and Walkthroughs

Different people use screen recording for different reasons. Recordful's combination of capture and editing tools supports several common workflows.

SaaS founders and product marketers

Record product demos, feature announcements, release updates, and onboarding videos. Automatic zoom, camera positioning, and visual effects help you create more polished demonstrations without editing every movement manually.

Developers and support teams

Capture bugs, reproduce issues, annotate errors, and explain fixes. Local recording and export are useful when you need to save a video without immediately uploading it to a cloud service.

Teachers and course creators

Create step-by-step lessons that show exactly where to click. Zoom controls, annotations, playback speed, and captions help learners follow the process and revisit specific instructions.

Sales and customer success teams

Demonstrate product workflows, explain features, and send customers a recording they can review at their own pace. Pro's shareable links can make distribution easier when you need to send videos regularly.

Privacy-conscious users

Record and review videos locally before deciding whether to upload or share them. The local-first workflow gives you more control over when a recording leaves your device.

6. Recordful vs. Loom: Which Screen Recorder Should You Choose?

Recordful and Loom support screen recording, but they emphasize different parts of the workflow.

Loom is built around recording and sharing videos through hosted links. Its free Starter plan currently lists a five-minute recording limit and a maximum of 25 videos per person. These limits can matter if you frequently record longer demonstrations or create many videos.

Recordful emphasizes local recording, video editing, visual effects, and automatic zoom. It offers unlimited local recordings in its free workflow, while Pro adds cloud storage and link sharing.

The better choice depends on what you need.

Choose a tool centered on hosted communication if your priority is quickly sending short video messages. Consider Recordful if you want more control over local recordings, visual presentation, and editing before sharing your work.

You can check Loom's current pricing and plan limits before comparing the two products.

Frequently Asked Questions About Recordful

Is Recordful free?

Yes. Recordful offers a free Chrome extension for local screen recording and video export. The free feature set includes recording without a watermark, with no recording-count limits or mandatory sign-in.

Cloud storage, link sharing, and additional premium capabilities are available through Recordful Pro.

Does Recordful support automatic zoom?

Yes. Recordful can place zooms around clicks to bring important interface elements into focus. You can adjust the zooms and use manual controls to customize the framing and movement.

Can I use Recordful without creating an account?

The free local recording workflow does not require you to sign in. Pro cloud services require the account or workspace setup needed to use those services.

Can Recordful record offline?

Recordful supports offline local recording by saving recordings in browser storage. Internet access is needed for cloud uploads and online sharing.

Which video formats does Recordful support?

The described export options include MP4, WebM, and GIF.

Can I share Recordful recordings through a link?

Yes. Recordful Pro provides cloud hosting and shareable links. You can configure recordings for workspace privacy or enable links that recipients can open without creating an account.

Is Recordful open source?

Yes. Recordful is distributed under the GPLv3 license, according to its project description.

How much does Recordful Pro cost?

The pricing described in this article is $7.99 per month or $59 per year, with a 14-day free trial for the yearly plan. Check the official pricing page for the latest terms.

Create Your Next Screen Recording With Recordful

A useful screen recording should do more than capture your display. It should help people understand your product, follow your instructions, and see the details that matter.

Recordful brings screen capture, annotations, automatic zoom, editing, audio controls, and export tools into one Chrome-based workflow. You can start with local recording for free and use Pro when you need cloud storage, captions, and shareable links.

Whether you are explaining a bug, documenting a workflow, teaching a lesson, or demonstrating a new feature, Recordful gives you a way to turn a raw screen capture into a clearer, more polished video.

Try Recordful and make your next screen recording easier to follow.

Read the full article on Forg →

And why I'm weirdly happy I never built my idea.

The idea I almost built

I had an idea.

An AI agent that lives on its own computer. Signs into your apps. Works while you sleep. Pings you only when it needs your approval.

I got excited. I opened a doc. I started sketching.

Then life happened. Classic.

Then this happened:

• August 11: SpaceXAI and Cursor launched Grok Bot. Every bot gets its own cloud computer and signs into the apps you already use.

• September 8: Meta launched Muse. Dedicated cloud VM. Sends emails, books travel, keeps working after you close the app.

• September 29: OpenAI launched Dots. Own cloud computer, own browser, 4,000+ apps through plugins.

Three launches. About seven weeks. My exact idea, three times, from companies with more GPUs than I have brain cells.

If I had started building, I'd be sitting on a dead product and a pile of wasted evenings.

I'm not sad about it. I'm relieved. Which is a strange thing to feel about a product that doesn't exist.

Why this is the new normal for SaaS

The old SaaS risk: a competitor copies you. You had months to react.

The new SaaS risk: the platform ships your product as a feature. You have a Tuesday.

And here's the kicker.

Your users already pay for ChatGPT or Claude. Your product costs extra. Their version is "included."

Guess who wins that fight.

There is no warning. No countdown. No "heads up, we're launching your startup next week."

That's what makes it a time bomb. Not that it explodes. That you can't hear the ticking.

Case file 1: Chegg

Chegg is the big one.

Its stock went above $100 in 2021. Subscribers grew from 1.5 million in 2016 to 8.2 million in 2022.

Then ChatGPT showed up and gave students the same homework help for free.

What followed:

• 22% layoffs in May 2025

• 45% layoffs in October 2025 (388 roles)

• Stock down roughly 99% from the peak

• An NYSE warning about possible delisting

Here's the detail I can't stop thinking about: AI was mentioned zero times in Chegg's 2022 annual report.

By its 2025 filing, the company was admitting students see tools like ChatGPT as strong alternatives to specialized products like Chegg.

Chegg even sued Google over AI Overviews.

Suing is not a moat.

Chegg is still operating. But it's managing decline, not growth.

Case file 2: Stack Overflow

Stack Overflow peaked at around 207,000 new questions a month in 2014.

The numbers today depend on which tracker you trust. The gentlest one shows a drop of about 75%. The harshest one counted just 1,304 questions in July 2026.

No version of that chart looks healthy.

To be fair, the decline started years before ChatGPT. Strict moderation and the whole "search first, you idiot" culture didn't help.

But AI changed the math. Asking a chatbot is instant and nobody downvotes you. IDE assistants removed the act of asking altogether.

Both things are true. AI just stepped on the gas.

Case file 3: The small ones nobody tweets about

The giants get the headlines. The small teams get the funerals.

• Relay: a five-year-old AI workflow automation tool, pitched as a Zapier alternative. Shut down in September 2026 as OpenAI, Google and others built similar automation into their own products.

• Huxe: an AI audio app from ex-NotebookLM developers. Shut down in May 2026, partly because bigger platforms offered similar experiences to huge existing audiences.

• Notion Mail: launched in April 2025, shutting down September 22. Reason: users were handing their inboxes to separate AI agents anyway.

And even OpenAI kills its own stuff.

The Atlas browser lasted less than a year before being folded into ChatGPT. Same story with Operator.

If OpenAI won't keep standalone products alive, your side project doesn't get a special exemption.

Not every SaaS is doomed

Quick reality check.

Chegg had problems before ChatGPT. So did Stack Overflow. AI wasn't the only factor.

And plenty of software is much harder to replace with a prompt.

The pattern is not "all SaaS dies." The pattern is "thin SaaS dies first."

The test I now run before building anything

Ask one question:

If OpenAI, Anthropic, Google or Meta shipped this exact feature tomorrow, would my customers still stay?

If your honest answer is "uh...", you're holding a ticking clock.

From what I've seen, the things that tend to survive:

• Data they can't get elsewhere. Proprietary, accumulated, hard to copy.

• Deep workflow. Embedded in how a team actually operates, not a nice add-on.

• Trust and distribution. Compliance, relationships, a community that shows up.

• Boring niches. Things the labs won't bother building.

That's my take, not a law of physics. But it's the filter I use now.

What I learned

I almost spent months on something three giants shipped within seven weeks.

One day of research saved me from that.

So before you build, spend a day checking whether the giants are about to. It's the cheapest due diligence you'll ever do.

And if they already did? Congrats. You just saved your semester.

What I'm building instead

My new rule: build things the big AI companies are unlikely to build.

Not because AI is bad. I use it every day.

But the labs chase the big, general-purpose stuff. A narrow tool where AI isn't the main point? Rarely on their roadmap.

So I'm building recordful.app.

It's a Chrome extension for screen recording.

You hit record. You hit stop. And it instantly turns your raw recording into an edited video you can customize.

No dragging clips around a timeline. No "I'll edit it later" that never happens.

The core of it isn't AI. It's a workflow and a product experience.

That's exactly the kind of thing I don't expect a trillion-dollar lab to ship next Tuesday.

Could I be wrong? Of course.

That's why I keep running the test.

Read the full article on Forg →

For students, developers, and anyone balancing several responsibilities at once, this becomes especially important. When you have assignments, personal projects, appointments, and everyday responsibilities competing for your attention, simply remembering everything can become a task of its own.

A good time-management system should therefore do more than give you a list of things to do. It should help you turn your intentions into actions.

Start by getting everything out of your head

One of the simplest ways to manage your time better is to stop relying on your memory.

When a task comes into your mind, write it down. It could be something as small as replying to an email or as large as finishing a project. The important thing is that you have somewhere reliable to put it.

This gives you a single place to see what actually needs to be done instead of constantly thinking:

I need to remember to do that later.

Once a task is written down, your brain does not have to keep reminding you about it.

Separate tasks by importance

Not every task deserves the same amount of attention.

A useful approach is to ask yourself two questions:

• Does this need to be done soon?

• How important is it?

Something that is both important and urgent should usually come first. Something important but not urgent can be planned for later. Small tasks can be handled when you have spare time.

This prevents your task list from becoming a collection of equally important-looking items.

Break large tasks into smaller actions

"Finish my project" is technically a task, but it does not tell you what to do next.

Instead, break it down:

• Create the database

• Build the login page

• Connect the API

• Test authentication

• Fix mobile layout

• Deploy the project

Now you can start with one concrete action rather than trying to figure out the entire project at once.

This also makes progress easier to see. Completing several small tasks can feel much more manageable than staring at one enormous unfinished task.

Give your tasks a time and a place

A task list tells you what you need to do. Your schedule determines when you will actually do it.

For example, instead of writing:

Study databases

you could plan:

Study databases — Tuesday, 17:00–18:00

This small difference makes your intention much more concrete.

However, you do not need to schedule every minute of your day. Leave enough flexibility for unexpected work, breaks, and things that take longer than expected.

Review your tasks regularly

A task-management system only works if you actually look at it.

Take a few minutes at the beginning or end of your day to review what you have planned. Check what you completed, what still needs attention, and whether anything needs to be moved.

You can also use a weekly review to look at bigger goals and make sure your daily tasks are moving you toward them.

The goal is not to create a perfect schedule. The goal is to maintain awareness of what is happening.

Use a task manager instead of relying on memory

This is where a dedicated task manager can make the process easier.

Instead of keeping tasks in scattered notes, messages, browser tabs, or pieces of paper, you can keep them in one place and organize them as your workload changes.

LogHue Tasks is designed around this simple idea: give your tasks a focused place where you can create, organize, and work through them without unnecessary complexity.

You can use it for something as simple as:

• School assignments

• Personal projects

• Coding tasks

• Things you need to remember

• Short-term goals

• Everyday responsibilities

The point is not to make managing tasks another complicated project. It is to make the process of knowing what to do next easier.

Keep the system simple

One of the biggest mistakes in productivity is spending more time managing the productivity system than actually doing the work.

You do not need dozens of categories, complicated workflows, or an elaborate productivity method.

A simple system can be enough:

Capture → Organize → Prioritize → Do → Review

Capture what needs to be done. Organize it so you can find it. Prioritize what matters. Do the work. Then review what remains.

The tool should support this process rather than become the process itself.

Time management is really attention management

You cannot create more hours in a day. What you can control is where you put your attention.

A long task list does not automatically mean you are productive. Completing one important task can be more valuable than checking ten insignificant ones off your list.

Good time management therefore starts with a simple question:

What deserves my attention right now?

Once you know the answer, a good task manager can help you keep track of everything else without constantly carrying it around in your head.

That is the purpose behind LogHue Tasks: keeping your tasks organized and accessible so you can spend less time trying to remember what needs to be done and more time actually doing it.

Read the full article on Forg →

Scybud didn't start with a business plan.

It started with me building things I personally needed.

I've always gotten a lot of my ideas that way. Instead of sitting down and trying to invent a startup idea, I usually run into a problem, think “I could build something for this,” and start building.

That has been one of the biggest reasons Scybud has evolved the way it has.

The journey so far hasn't been a straight line. Ideas changed. Products grew into things I didn't originally expect. Some projects became useful in ways I hadn't planned for. And a lot of what I know today came from simply trying to make something work.

How Scybud Started

In the beginning, Scybud was essentially a collection of things I wanted to build.

I wasn't trying to create an ecosystem from day one.

I was learning web development by actually making products. When I needed something, I built it. When I didn't understand something, I researched it. When something broke, I tried to figure out why.

That approach has been extremely useful to me because I learn much better when there is an actual problem to solve.

It also means that many of my ideas start very small.

LogHue is probably the best example.

LogHue Started Very Simply

The original LogHue was almost ridiculously simple compared to what it is today.

The idea was basically: Log what you did.

You would record your activities and they would be stored in the browser's local storage.

That was it.

The underlying idea, though, was more important than the implementation.

I wanted people to be accountable for their activities. To have a record of what they actually did instead of relying on memory or vague feelings about whether they had been productive.

As I kept working on it, I started thinking about how it could become something much bigger.

I moved toward a workspace-centric platform where teams could work together.

Technically, that direction made sense.

But something felt wrong.

It wasn't really the original LogHue idea anymore.

The core concept of accountability had been pushed into the background.

So instead of simply continuing in that direction, I went back to the original idea.

That led me to focus more heavily on LogHue Tasks.

And that ended up changing the entire direction of the product.

Separate, But Connected

While working on LogHue Tasks, I started thinking differently about how the products should work.

I didn't necessarily need one enormous application that tried to do everything.

What if the tools were separate, but connected?

That became one of the most important ideas in the Scybud ecosystem.

Tasks could be their own thing.

Notes could be their own thing.

Workspaces could be their own thing.

But they shouldn't feel isolated.

For example, tasks can connect to notes. Tasks can also be added directly to workspaces in just a few clicks.

Notes can be exported and imported into workspaces. They can also be shared publicly through a link.

Instead of forcing everything into one giant interface, each product can focus on its own purpose while still being useful with the others.

That sounds obvious now, but I didn't start with that architecture.

I arrived at it by building.

Working Alone Doesn't Have to Mean Working Alone Forever

Another idea that came from this process was the concept of being able to work alone and then move into a team without having to completely change how you work.

A lot of productivity software seems to assume that you're either an individual user or part of a team.

I liked the idea of making that transition much easier.

You could start working on your own.

Build your tasks.

Write your notes.

Organize your work.

And when you eventually need other people involved, you can move into a workspace and start collaborating.

The products remain useful individually, but the ecosystem gives you a path toward working with others.

That became much closer to what I originally wanted LogHue to be.

I Learn by Building

A lot of my development journey has happened in the same way.

I don't always learn a technology first and then decide what to build with it.

Usually, I build something and learn whatever I need along the way.

That has taken me through databases, authentication, APIs, browser extensions, deployment, payments, web applications, UI systems, and a lot of other areas.

It has also changed how I use AI.

AI has become part of how I learn and build.

I can ask questions when I don't understand something, use it to investigate errors, get explanations, and work through problems that would otherwise take me much longer to solve.

But there is a downside.

Sometimes I get lazy.

I can ask AI to help me fix something, see that the problem appears to be solved, and move on without properly reviewing what was changed.

And sometimes I regret that later.

The code might work, but I don't fully understand it anymore. Or I discover that the solution created another problem somewhere else.

That's taught me an important lesson about using AI for development:

AI can help me build faster, but it can't replace understanding what I'm building.

The responsibility for the code is still mine.

Keeping the Stack Simple

There is another decision that has shaped almost everything I've built under Scybud: I try to keep the technology stack simple.

Most of these projects have been built using HTML, CSS, JavaScript, and TypeScript, without adding a large number of extra technologies or frameworks.

That isn't because I think other technologies are bad.

It's because I'm a solo developer managing multiple projects at the same time.

Every additional technology introduces something else I have to maintain, understand, update, debug, and remember across different projects. When you're working on one project, that might not matter much. When you're maintaining several, it adds up.

For me, keeping the stack relatively simple makes it easier to move between projects.

I can open a project, understand what is happening, make a change, and move on without having to remember a completely different architecture for every product.

But eventually, I started noticing another problem.

I was repeatedly building the same kinds of UI components.

Buttons. Cards. Inputs. Modals. Navigation elements. Other small pieces that every project needed.

I could keep rebuilding them, but that didn't make much sense.

So I started building Scybud UI.

The idea was simple: create a reusable UI system that I could use across my own projects instead of rebuilding the same things every time.

That made Scybud UI more than just another project. It became a solution to a problem created by Scybud itself.

The more projects I built, the more useful a shared UI system became.

And that is actually a pattern I've noticed throughout the Scybud journey.

I don't always start with a grand plan for an ecosystem.

I build something because I need it.

Then I build more things.

Eventually, I notice that some of those things could work better together.

And sometimes, the solution to a problem created by one project becomes another product entirely.

Building Products Has Changed How I Think

One thing I didn't expect when I started building projects was how much product development would change the way I think.

When you're just writing code, a problem can seem very technical.

When you're building an actual product, you start asking different questions.

Does this feature actually make sense?

Does it solve the original problem?

Is this easier for the user?

Should these things be connected?

Should they even be in the same product?

Those questions have influenced Scybud much more than any particular programming language or framework.

The products have evolved because my understanding of the problems has evolved.

Scybud Became an Ecosystem

Eventually, the same thinking started applying beyond LogHue.

Scybud became a place for different products that solve different problems.

LogHue and LogHue Notes became part of the productivity side.

TryTasty explored recipes and food discovery.

ZeFeed explored technology news.

CanvArt explored digital art sharing.

DakAt became a browser extension for customizing websites.

PropDek explored property-related ideas.

RushSite focused on quickly creating portfolio websites.

And Scybud UI grew out of something I needed across my own projects: a reusable UI system so I didn't have to keep rebuilding the same components.

Not every product has the same purpose.

That's intentional.

The goal isn't to make every product do everything.

The goal is to create products that can stand on their own while still making sense within the larger ecosystem when there is a genuine connection.

The Ups

There have been plenty of moments that made the work feel worthwhile.

Seeing a product actually work after spending so much time building it is one.

Getting the first users is another.

Seeing search traffic appear.

Getting backlinks.

Making the first bit of revenue.

Watching something I built become useful to another person.

Those moments might seem small from the outside, but when you're building mostly by yourself, they mean a lot.

They are proof that something that started as an idea in your head has actually become real.

The Downs

But there have also been plenty of frustrating moments.

Building something doesn't guarantee that people will use it.

I can spend a lot of time polishing a product and still have very little traffic.

A technically good product can still struggle to get attention.

Sometimes I make decisions that I later have to undo.

Sometimes I build something in a way that seemed reasonable at the time and then realize that I created unnecessary complexity.

And sometimes the biggest problem is me.

Especially when I rush.

Using AI has made some things faster, but it has also made it easier to move too quickly without fully understanding what happened underneath.

I've had moments where I looked back at code and thought, why did I let this become like this?

Those moments are frustrating, but they are also part of learning how to actually engineer software rather than simply getting software to work.

Where Scybud Is Now

Scybud is very different from what it was at the beginning.

There are now multiple live products, shared infrastructure, a UI system, connected applications, and a much clearer idea of what I want the ecosystem to become.

But I don't consider it finished.

I don't even think I'm close.

There are still plenty of things I want to improve, and there are still problems I haven't solved.

The biggest difference is that I now have a much better understanding of why I'm building things.

I'm not just trying to make a website because I can.

I'm trying to solve problems that I encounter, and then figure out whether the solution can be useful beyond myself.

That's been the real journey.

Still Building

If there is one thing that defines Scybud for me, it's probably this:

It keeps evolving.

An idea starts small.

I build it.

Building exposes problems.

Those problems lead to new ideas.

The new ideas change the product.

The product changes how I think.

And then that experience influences whatever I build next.

That's how LogHue went from a simple local-storage activity logger to a connected productivity ecosystem.

That's how separate products started becoming a connected system.

That's how I ended up building my own UI library.

And that's how I learned that using AI effectively isn't just about getting code generated, it's about asking the right questions and actually understanding the answers.

I don't know exactly what Scybud will look like years from now.

I didn't know what it would look like today when I started.

For now, I'm still doing what I've been doing from the beginning:

I find something I need.

I think about how it could work.

And then I build it.

Read the full article on Forg →

Introduction: Meet JEV, the Model That Stopped Talking

Picture this.

You walk into a restaurant, and instead of a chatty waiter who tells you the entire history of every dish, explains every ingredient, shares the chef's grandmother's recipe, and gives you their personal opinion about truffle oil, you get a silent maître d' who simply points to the best option and gives you a confidence score.

That, in a nutshell, is JEV.

JEV, sometimes stylized as "Jev," is not your typical AI model. It does not write essays. It does not compose poetry. It will not help you draft a breakup text, although that might honestly be for the best.

What JEV does is make decisions.

Fast, cheap, typed decisions with calibrated probabilities.

Think of it as an extremely opinionated spreadsheet that actually understands context.

Released in early access on September 15, 2026, by TypeSafe AI, JEV arrived with $40 million in seed funding and a notable AI research pedigree. Its founder, Diogo Almeida, is a former OpenAI researcher credited as a co-inventor of RLHF, or Reinforcement Learning from Human Feedback, the technique that helped turn raw language models into the helpful assistants we know today.

The name "JEV" comes from William Stanley Jevons, a 19th-century economist famous for the Jevons paradox. The paradox describes how making resource use more efficient can sometimes lead to greater overall consumption.

TypeSafe essentially made a similar bet with AI.

If AI decisions become radically cheaper and faster, people may start using AI for decisions they previously considered too expensive or impractical to automate.

It is a clever name. Although "William Stanley" would have been considerably funnier.

Within 24 hours of launch, JEV reportedly saw adoption from a significant percentage of paid Vercel AI Gateway teams. There were also reports of TypeSafe discussing a major funding round at a multibillion-dollar valuation shortly after launch.

The hype was real.

The memes were arguably better.

What JEV Actually Does

The "No-Text" Revolution

The Core Concept: System One Thinking

TypeSafe describes JEV as a "System One Model," borrowing terminology from psychologist Daniel Kahneman's framework in Thinking, Fast and Slow.

Kahneman describes two broad styles of thinking:

System 1 is fast, intuitive, automatic, and reactive.

System 2 is slower, deliberate, analytical, and reasoning-heavy.

Traditional LLMs such as GPT and Claude are fundamentally built around generating sequences of tokens. Even when the final answer is simply "yes" or "no," the model still operates through the machinery of language generation.

JEV takes a different approach.

It does not need to generate a paragraph explaining its reasoning before producing an answer.

Instead, it looks at a situation and produces a structured decision in a single forward pass.

A Simple Example

Imagine you are running a customer support system.

A traditional LLM workflow might look like this:

1. Receive a support ticket.

2. Send the ticket to the LLM.

3. Ask what should happen with the ticket.

4. The LLM generates a detailed explanation about the customer's tone, product category, severity, and possible solutions.

5. Your application then extracts the actual decision from that response.

6. The ticket gets routed to the appropriate department.

With JEV, the workflow can be much simpler:

1. Receive the support ticket.

2. Send JEV the ticket and one typed question: "Which department should handle this? Billing, sales, or technical?"

3. JEV returns a structured result such as:

{
  "choice": "billing",
  "confidence": 0.87,
  "probabilities": {
    "billing": 0.87,
    "sales": 0,
    "technical": 0.13
  }
}

4. Your application routes the ticket.

Done.

There is no generated essay to parse. There is no unexpected markdown. There is no need to extract a decision from a paragraph of text.

The Three Decision Types

JEV answers questions using three primary formats.

That constraint is the entire point.

1. Choice

Choice questions ask the model to select one option from a predefined list.

For example:

Is this ticket about billing, sales, or technical support?

JEV returns the selected option along with probabilities for the possible choices.

This is useful for:

• Classification

• Routing

• Categorization

• Tool selection

• Model routing

• Workflow decisions

2. Score

Score questions ask the model to evaluate something on an ordinal scale.

For example:

How frustrated is this customer on a scale from 0 to 2?

Where:

• 0 = Calm

• 1 = Frustrated

• 2 = Very angry

JEV returns a score along with confidence information.

This makes it useful for:

• Severity assessment

• Risk scoring

• Priority assignment

• Sentiment estimation

• Quality evaluation

3. Noul

Noul is a calibrated yes or no probability.

For example:

Is this refund request eligible for automatic approval?

Instead of simply returning yes or no, JEV can return a probability between 0 and 1.

For example:

{
  "noul": 0.95
}

This means the model estimates a 95% probability for the requested outcome.

The important distinction is that JEV does not just give you a binary answer. It gives you a measurable degree of confidence.

Why Typed Outputs Matter

One of JEV's most important characteristics is that its outputs are typed.

Traditional LLM applications often have to deal with problems such as:

• Invalid JSON

• Missing fields

• Unexpected keys

• Markdown appearing where JSON was expected

• Text appearing instead of a structured value

• The model changing the requested format

JEV is designed around a constrained output system.

A Choice question produces a Choice.

A Score question produces a Score.

A Noul question produces a Noul probability.

The model cannot suddenly decide that a Choice question should return a poem.

This makes JEV particularly interesting for software systems where AI decisions need to feed directly into deterministic application logic.

The Input Format: State + Questions

Using JEV is conceptually simple.

You provide two main things:

State

The state contains the context the model should evaluate.

This could be:

• A support ticket

• A user profile

• A log entry

• A piece of code

• A document

• A medical record

• A JSON object

• Unstructured text

The state can contain up to 32,000 tokens.

Think of the state as the evidence.

Questions

Questions tell JEV what decisions you want it to make about that evidence.

Each question specifies:

• The question type

• The available choices or scale

• The description of what should be evaluated

Multiple questions can be evaluated against the same state.

For example, suppose you have a customer support ticket:

{
  "ticket": {
    "subject": "Duplicate charge",
    "message": "I was charged twice for order A-104. Please help."
  }
}

You could ask three questions at once:

{
  "is_urgent": {
    "type": "noul",
    "description": "Does this require immediate attention?"
  },
  "department": {
    "type": "choice",
    "options": [
      "billing",
      "sales",
      "technical"
    ]
  },
  "frustration": {
    "type": "score",
    "scale": {
      "0": "Calm",
      "1": "Frustrated",
      "2": "Very angry"
    }
  }
}

JEV might return something like:

{
  "is_urgent": {
    "type": "noul",
    "noul": 0.95
  },
  "department": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.87,
    "probabilities": {
      "billing": 0.87,
      "sales": 0,
      "technical": 0.13
    }
  },
  "frustration": {
    "type": "score",
    "score": 1.04,
    "confidence": 0.94,
    "probabilities": {
      "0": 0,
      "1": 0.96,
      "2": 0.04
    }
  }
}

Notice what happened.

Three different decisions were evaluated in a single call.

This is important because JEV evaluates multiple questions in parallel rather than requiring separate model calls for each question.

That means you can build a complete decision profile around a piece of information without repeatedly sending the same state through the model.

How JEV Works Under the Hood

The Architecture: Skipping Autoregression

This is where things become technically interesting.

Traditional LLMs are autoregressive.

They generate text one token at a time.

For example:

"The cat sat on the..."

The model predicts:

"mat"

Then the sequence becomes:

"The cat sat on the mat..."

The model then predicts the next token.

This process continues until the response is complete.

That sequential generation is one of the reasons LLMs can be relatively slow for simple tasks.

Even if you only need the answer "yes," the underlying model is still designed around language generation.

JEV takes a different approach.

TypeSafe describes its architecture as using a parallel sampler.

The model reads the state and produces its decisions in a single forward pass.

There is no token-by-token generation of an explanation.

There is no need to produce a chain of text before arriving at the final decision.

The output is the decision itself.

What We Know About the Architecture

TypeSafe has not publicly released every detail of JEV's architecture, weights, or training process.

The company describes JEV as transformer-based and trained using synthetic data.

That means there is still a significant amount of uncertainty around the exact technical implementation.

This matters because many of JEV's strongest claims are difficult for outside researchers to independently reproduce without access to the underlying model and training details.

The lack of transparency has therefore attracted skepticism from parts of the AI research community.

At the same time, the model has attracted considerable developer interest.

Why JEV Can Be So Cheap

One of the biggest consequences of JEV's architecture is its output economics.

Traditional LLM APIs generally charge for both input and output tokens.

Output generation can be expensive because generating a response requires the model to repeatedly execute its generation process.

JEV does not generate a conventional text response.

Instead, the decision is produced as part of the model's forward pass.

As a result, TypeSafe charges primarily for input tokens, with output effectively free under its pricing model.

The reported price is approximately:

$0.042 per million input tokens.

That is extremely low compared with many frontier language models.

At high volumes, the difference becomes substantial.

For example, processing thousands of decisions every day can become dramatically cheaper when the decision layer is handled by a specialized model instead of a general-purpose reasoning model.

This is one of the core economic arguments behind JEV.

RLCD: Reinforcement Learning for Calibrated Decisions

JEV's training approach is called RLCD, or Reinforcement Learning for Calibrated Decisions.

The idea is fundamentally different from traditional RLHF.

RLHF generally optimizes models toward responses that human evaluators prefer.

RLCD focuses more directly on whether the model's probabilities correspond to actual outcomes.

The goal is calibration.

If JEV says that something has an 87% probability, the ideal behavior is for roughly 87% of similarly confident predictions to be correct.

That sounds simple.

It is not.

Why Calibration Matters

Many AI systems are overconfident.

A model may give an answer with very high confidence even when it is wrong.

JEV's value proposition depends heavily on avoiding this problem.

Imagine a production system where JEV evaluates a decision.

You could create a system like this:

95% confidence

Automatically execute the action.

60% confidence

Send the decision to a human reviewer.

30% confidence

Send the request to a more powerful LLM for deeper analysis.

Now confidence becomes an operational control mechanism.

It is no longer just a number displayed beside an answer.

It becomes part of the architecture.

The Important Caveat: Calibration Is Not Perfect

This is one of the areas where JEV deserves careful evaluation.

Independent testers have reported calibration problems on certain datasets.

Other tests have shown that the model can still make significant content-level mistakes even when it follows the requested output schema perfectly.

This highlights an important distinction:

Schema correctness does not equal factual correctness.

JEV can guarantee that the answer has the correct structure.

That does not mean the decision itself is always correct.

A model can perfectly follow the requested schema and still make the wrong judgment.

This distinction is critical when using JEV in production.

The Speed Factor

Speed is one of JEV's strongest selling points.

Reported response times range from approximately 70 milliseconds to 500 milliseconds, with many practical calls landing around the 150 millisecond range.

Traditional LLM calls involving structured output can take several seconds depending on the model, prompt, infrastructure, and workload.

The difference becomes especially significant when you are processing large volumes of decisions.

Consider email classification.

If you need to classify thousands of emails, a model that takes several seconds per decision can become a bottleneck.

A decision model operating in hundreds of milliseconds can instead become part of a real-time pipeline.

That opens up applications such as:

• Content moderation

• Fraud detection

• Tool authorization

• Customer support routing

• Safety checks

• Real-time classification

• Model routing

• Automated workflow decisions

JEV is not simply trying to be a slightly faster chatbot.

It is targeting a different workload.

What People Are Actually Building With JEV

The ecosystem around JEV expanded rapidly after launch.

Developers started experimenting with it across many different categories.

Some of the strongest use cases are the ones where decisions are:

• Frequent

• Structured

• Repetitive

• Time-sensitive

• Easy to describe with a bounded set of outcomes

Here are some of the most interesting examples.

Content Moderation at Scale

This is one of the most obvious applications.

Large platforms receive enormous numbers of:

• Posts

• Comments

• Images

• Messages

• Reviews

• Uploads

Running every single piece of content through an expensive frontier LLM can become economically impractical.

JEV can act as a first-pass decision layer.

For example:

Clearly safe

Approve automatically.

Clearly unsafe

Block automatically.

Uncertain

Send to a human or a more powerful model.

This architecture allows expensive models to focus on ambiguous cases instead of processing everything.

Support Ticket Routing

Customer support is another natural fit.

A support ticket can be evaluated for:

• Urgency

• Department

• Customer frustration

• Product category

• Escalation requirement

Instead of asking a general-purpose LLM to explain everything about the ticket, JEV can directly produce the decisions required by the support system.

That makes the integration much simpler.

Agent Tool Selection

AI agents constantly make decisions about what to do next.

For example:

Should I search the web?

Should I check the calendar?

Should I call the database?

Should I ask the user for clarification?

Should I execute this action?

These are bounded decisions.

The agent does not necessarily need a massive reasoning model for every one of them.

A specialized decision model can handle these smaller decisions quickly.

Model Routing

Another powerful use case is model routing.

Imagine you have three models:

Cheap model

Fast and inexpensive.

Mid-tier model

More capable but more expensive.

Frontier model

Extremely capable but expensive and slower.

You could use JEV as the routing layer.

For every incoming request, JEV determines which model should handle it.

Simple requests go to the cheap model.

Moderate requests go to the mid-tier model.

Complex requests go to the frontier model.

This means you do not have to use your most expensive model for every request.

Evaluations and LLM-as-a-Judge

Evaluating AI outputs can itself be expensive.

For example, you might ask an LLM:

Which of these two responses is better?

Doing that millions of times can become expensive.

JEV can instead act as a lightweight evaluation model.

The same principle applies to:

• Preference evaluation

• Quality scoring

• Classification

• Benchmarking

• Response ranking

• Automated testing

A fast decision model can potentially handle the majority of straightforward judgments while a more capable model handles uncertain cases.

Fraud and Risk Scoring

Financial systems constantly make probabilistic decisions.

Examples include:

• Is this transaction suspicious?

• Is this insurance claim likely fraudulent?

• Should this application be escalated?

• Is this payment high risk?

• Does this transaction require additional verification?

These are naturally expressed as probabilities or classifications.

That makes them a strong conceptual fit for JEV.

However, high-stakes systems require much more than model confidence.

They also require:

• Regulatory compliance

• Bias testing

• Auditing

• Human oversight

• Robust evaluation

• Domain-specific validation

A fast model does not remove those requirements.

Code Review and Triage

JEV can also be used as a decision gate for software development.

For example:

Is this change a simple refactor or a complex architectural modification?

Simple changes could move through an automated workflow.

Complex changes could be escalated for human review or sent to a stronger reasoning model.

This creates another hybrid architecture:

JEV decides what kind of problem this is.

A stronger model solves the problem when necessary.

Creative Experiments

Developers have also experimented with JEV in more unusual environments.

Examples include:

• Game AI

• Minecraft bots

• Browser automation

• Poker decisions

• Crisis simulations

• Autonomous agents

• Mechanical control systems

One interesting description from a Minecraft experiment compared JEV's behavior to an insect making extremely fast mechanical decisions.

That is actually a useful mental model.

JEV is not necessarily trying to understand everything.

It is trying to decide what to do next.

The Jevons Paradox in Action

TypeSafe named the model after William Stanley Jevons for a reason.

The underlying economic idea is simple:

When something becomes dramatically cheaper and more efficient, people may use much more of it.

The same principle could apply to AI decisions.

Before JEV, you might avoid running an LLM over every user interaction because the cost would be too high.

With a much cheaper decision model, you can potentially evaluate every interaction.

The cost barrier drops.

As a result, entirely new automation patterns become economically practical.

Imagine being able to make thousands or millions of tiny AI decisions without worrying about the cost of a general-purpose LLM.

The result is not necessarily less AI usage.

It could be much more AI usage.

That is the Jevons paradox applied to AI infrastructure.

The Social Media Circus

No major AI launch survives the internet without memes, hot takes, speculation, and controversy.

JEV was no exception.

The Memes

The X community quickly turned JEV into a meme.

The jokes revolved around:

• How cheap it was

• How quickly it made decisions

• Its association with crypto

• The model's name

• The idea of an AI that "just decides"

A memecoin also appeared around the JEV name, creating another layer of internet speculation around an already heavily discussed AI launch.

This became an amusing example of the same economic phenomenon JEV was named after.

Make decisions cheaper, and people will apparently use those decisions for increasingly ridiculous things.

The Skepticism

The excitement was accompanied by skepticism.

Some developers argued that many of the ideas behind JEV resemble existing machine learning approaches.

Others pointed out that there is still limited public information about:

• The internal architecture

• Training methodology

• Model size

• Training data

• Independent evaluations

• Reproducibility

This creates an important distinction between the concept and the implementation.

The concept of a specialized decision model is straightforward and compelling.

The more difficult question is whether JEV's specific implementation actually delivers the performance, calibration, and economics being claimed.

That question requires independent testing.

The Genuine Enthusiasm

Despite the skepticism, many developers have reported impressive early results.

Some users have reported JEV making routing decisions in roughly one second, compared with several seconds for conventional LLM approaches.

Other developers working on high-scale AI systems have pointed out that many of their workloads do not actually require a full-scale reasoning model.

For these workloads, a model that is significantly cheaper and faster could be extremely useful if its accuracy is sufficient.

This is probably the most important argument in favor of the JEV approach.

It does not need to replace frontier models.

It simply needs to handle the decisions that frontier models are unnecessarily expensive for.

The Technical Difference

JEV vs. Traditional LLMs

The easiest way to understand the distinction is to look at what each system is optimized to do.

Traditional LLMs

Traditional LLMs are designed for open-ended language generation.

They can:

• Write text

• Explain concepts

• Reason through problems

• Generate code

• Summarize documents

• Follow complex instructions

• Have conversations

• Produce creative content

Their flexibility is their greatest strength.

It is also one reason they can be inefficient for simple decisions.

JEV

JEV is designed for bounded decisions.

It focuses on:

• Choices

• Scores

• Probabilities

• Classification

• Routing

• High-volume judgments

Instead of generating a paragraph, it produces a structured decision.

Instead of optimizing for expressive language, it optimizes for fast decision-making.

Instead of being a replacement for general-purpose LLMs, it is better understood as a specialized component that can sit alongside them.

The Critical Insight: They Are Complementary

The most interesting architecture is not necessarily:

JEV versus GPT.

It is:

JEV plus GPT.

A production system could use JEV for the simple, high-volume decisions and a frontier model for the difficult cases.

For example:

1. Receive a request.

2. JEV determines the request type.

3. Simple requests go to a cheap model.

4. Moderate requests go to a stronger model.

5. Complex or uncertain requests go to a frontier model.

6. High-risk actions require human approval.

This creates a layered AI architecture.

Each model does the job it is best suited for.

The Batching Superpower

One of JEV's most interesting features is its ability to evaluate multiple questions against the same state.

Imagine receiving a customer support message.

Instead of making separate calls for:

• Spam detection

• Urgency

• Sentiment

• Department

• Product category

• Escalation

• Refund eligibility

You can potentially ask all of these questions in a single call.

Because the questions are evaluated against the same state, they can run in parallel.

This can dramatically reduce both latency and cost.

The architectural implications are significant.

Instead of building:

Check spam
    ↓
Check urgency
    ↓
Check sentiment
    ↓
Determine department
    ↓
Determine priority
    ↓
Decide whether to escalate

You can conceptually build:

              ┌─ Spam
              ├─ Urgency
              ├─ Sentiment
State ────────┼─ Department
              ├─ Priority
              └─ Escalation

Everything is evaluated against the same piece of information.

That can make AI pipelines much more efficient.

The Confidence Cascade Pattern

This is arguably one of the most practical patterns for using JEV in production.

The basic architecture is:

Step 1

Send a decision to JEV.

Step 2

Read the confidence score.

Step 3

If confidence is above 90%, automatically execute the decision.

Step 4

If confidence is between 50% and 90%, send the decision to a human.

Step 5

If confidence is below 50%, escalate to a more powerful LLM.

The exact thresholds should depend on the application.

A low-risk application might tolerate a lower threshold.

A high-risk application may require extremely high confidence and additional verification.

The important idea is that the model's confidence becomes part of the control flow.

Why This Architecture Is Powerful

Consider a system processing one million requests.

If you send every request to a frontier model, you pay the frontier model's cost for all one million requests.

If JEV can confidently resolve 90% of those requests, you only need the expensive model for the remaining 10%.

That changes the economics dramatically.

The architecture becomes:

                ┌── High confidence → Execute
Incoming ───── JEV
                ├── Medium confidence → Human review
                │
                └── Low confidence → Stronger LLM

The frontier model becomes the exception rather than the default.

Limitations and Honest Drawbacks

JEV is interesting, but it is not magic.

There are several important limitations.

1. JEV Does Not Calculate

JEV should not be treated as a traditional calculator.

Arithmetic, counting, and date comparisons should remain in deterministic code.

If your application needs to add numbers, use a calculator or regular code.

Do not ask the AI to perform a task that software can perform exactly.

2. It Is Text-Only

JEV is designed around text-based decisions.

It is not a multimodal model for directly processing:

• Images

• Video

• Audio

If your decision depends on an image or video, another system must first convert that information into usable state.

3. Calibration Is Not Perfect

Confidence scores are useful only if they are actually calibrated.

Independent tests have reported calibration problems on certain datasets.

Therefore, production systems should validate calibration on their own data rather than blindly trusting the confidence value.

4. JEV Can Still Be Wrong

Typed output does not guarantee correct output.

A model can return perfectly valid JSON, select a valid option, and still make the wrong decision.

This is perhaps the most important thing to understand about JEV.

Format reliability is not the same as decision reliability.

5. Adversarial Inputs Still Matter

JEV can still be affected by malicious or carefully constructed inputs.

Prompt injection and adversarial examples remain relevant concerns.

Production systems therefore need:

• Input validation

• Edge-case testing

• Security controls

• Monitoring

• Human escalation

• Domain-specific evaluation

6. It Is Closed Source

JEV does not currently provide the same level of transparency as fully open models.

Developers cannot simply download the model, inspect the weights, self-host it, or fine-tune it in the same way they can with open-weight alternatives.

This may become important for companies with strict infrastructure, privacy, or compliance requirements.

The Future of Decision Models

The Rise of "System One" as a Model Category

The biggest idea behind JEV may not actually be JEV itself.

It may be the creation of a distinct category of AI models designed specifically for decision-making.

If this approach works, we could see specialized decision models emerge for many domains.

For example:

Healthcare

Models specialized in clinical classification and triage decisions.

Legal

Models specialized in contract classification, risk detection, and clause analysis.

Security

Models specialized in threat classification and incident prioritization.

Finance

Models specialized in fraud detection, risk scoring, and transaction classification.

Software

Models specialized in code triage, issue classification, and tool routing.

The broader pattern would be:

One model generates.

Another model reasons.

Another model decides.

Another model verifies.

Instead of one enormous model doing everything, AI systems could become collections of specialized components.

Decision Models at the Edge

Because decision models can be smaller and faster than general-purpose language models, they may also become useful on local devices.

Potential applications include:

• Real-time safety systems

• Autonomous devices

• Voice assistant routing

• On-device classification

• Robotics

• Smart cameras

• Industrial monitoring

The key advantage would be latency.

If the decision only needs to happen in milliseconds, sending information to a remote frontier model may be unnecessary.

A specialized local model could potentially make the decision immediately.

The Open Source Response

No popular AI architecture remains uncontested for long.

Open-source projects have already begun experimenting with the concept of System One decision models.

Some aim to reproduce JEV's interface.

Others may attempt to build alternative architectures that are:

• Cheaper

• Faster

• More transparent

• Self-hostable

• Fine-tunable

Whether open alternatives can match JEV's calibration and performance remains an open question.

But the underlying idea is now public.

Decision-only AI models are a concept developers can build independently.

Enterprise Adoption

JEV launched with an early-access model and a waitlist.

Demand reportedly became strong enough that new signups were temporarily paused.

However, early developer enthusiasm is not the same thing as enterprise adoption.

The real questions are much harder:

• Can the system handle enormous production workloads?

• Does calibration remain reliable at scale?

• Does accuracy remain consistent across different domains?

• Does pricing remain sustainable?

• Can enterprises trust the system with high-impact decisions?

• Can it meet compliance requirements?

• Can organizations audit its behavior?

Those questions will determine whether JEV becomes an important piece of AI infrastructure or remains primarily an impressive new model.

The Regulatory and Trust Question

Decision models become much more complicated when they enter high-stakes systems.

Consider:

• Credit approval

• Medical triage

• Hiring

• Insurance

• Financial fraud detection

• Legal decisions

Suppose an AI model approves a loan with 95% confidence and the loan later defaults.

Who is responsible?

Now imagine the same system consistently produces different outcomes for different demographic groups.

That creates an entirely different problem.

Calibration does not automatically solve fairness.

A probability can be perfectly calibrated while the underlying decision process still produces unacceptable outcomes.

As a result, high-stakes AI systems will require:

• Independent audits

• Domain-specific testing

• Bias evaluation

• Human oversight

• Clear accountability

• Regulatory compliance

The confidence score is useful.

It is not a substitute for governance.

What JEV Gets Right

JEV is interesting because it attacks a very specific inefficiency in modern AI systems.

A huge number of AI tasks do not actually require an essay.

They require a decision.

For example:

Is this spam?

Should this request go to billing?

Is this transaction suspicious?

Should this agent call the search tool?

Is this request simple or complex?

Using a massive generative model for every one of these questions can be unnecessarily expensive.

The architectural insight is straightforward:

Not every AI problem needs a model that talks.

Sometimes you need a model that decides.

By removing unnecessary text generation, a specialized decision model can potentially achieve major improvements in speed and cost.

The Most Interesting Part: Confidence as a Control System

The confidence cascade may be the most practically important idea here.

Traditional AI applications often treat model output as a final answer.

JEV encourages a different pattern.

The model can instead become a control mechanism.

For example:

High confidence

Proceed automatically.

Medium confidence

Ask for human review.

Low confidence

Call a more powerful model.

This turns AI confidence into a programmable threshold.

You can tune the system according to the risk of the action.

For a harmless recommendation, 80% confidence might be enough.

For a financial transaction, it might not be.

For a medical decision, you may require substantially more safeguards.

The model becomes one component in a larger decision system.

What Makes JEV Uncertain

The biggest concern is not the concept.

The concept makes sense.

The uncertainty lies in the implementation.

JEV is a very new model.

Its internal architecture is not fully public.

Its long-term reliability has not been established.

Its independent benchmark coverage is still limited.

Its calibration claims require continued testing.

That means the right way to evaluate JEV is not to ask:

"Is JEV revolutionary?"

The better question is:

"Does JEV reliably solve this specific decision problem better than the alternatives?"

That is something developers can actually measure.

JEV Is Not a Replacement for GPT or Claude

This distinction is important.

JEV is not designed to replace general-purpose language models.

It does not aim to:

• Write a novel

• Build an entire application from scratch

• Explain a complicated mathematical proof

• Have a long conversation

• Generate a marketing campaign

• Produce a detailed technical tutorial

Those are generative or reasoning-heavy tasks.

JEV is designed for something narrower:

Make a decision.

That makes the most compelling architecture a hybrid one.

Use a specialized decision model for simple, repetitive, high-volume decisions.

Use a powerful reasoning model when the problem actually requires reasoning.

Use deterministic software whenever a task does not require AI at all.

That last point matters just as much.

If normal code can solve a problem perfectly, AI should not be used simply because it is available.

The Bigger Idea

For years, AI development has focused on building models that are:

• Bigger

• More general

• More capable

• Better at reasoning

• Better at generating language

JEV represents a different direction.

Instead of asking:

How can we make the model do everything?

It asks:

What if we build a model that does one thing extremely efficiently?

That shift could become important.

The future may not consist of one enormous model responsible for every part of an AI system.

Instead, an AI stack could look more like a collection of specialized components:

User Input
    ↓
Decision Model
    ↓
Routing Layer
    ├── Simple task → Cheap model
    ├── Generation → Generative model
    ├── Complex reasoning → Frontier model
    └── High-risk action → Human

Each component performs a specific role.

This resembles how traditional software systems are built.

You do not use one piece of software for everything.

You use databases for storage, search engines for retrieval, queues for messaging, and application code for business logic.

AI may evolve in the same direction.

Conclusion: The Silent Revolution

JEV represents a subtle but potentially important shift in AI architecture.

For years, the industry has chased larger, more general, more conversational models.

JEV asks a different question:

What if the future of AI also includes models that are smaller, faster, quieter, and specialized?

What if the best AI system is not one enormous model that does everything?

What if it is an ecosystem of specialized components?

A fast decision layer.

A slow reasoning layer.

A creative generation layer.

A verification layer.

Each component doing the job it is best suited for.

JEV is still extremely young.

Its benchmarks are still developing.

Its long-term reliability remains unproven.

Its architecture is not fully transparent.

Its calibration needs continued independent evaluation.

But the underlying idea is difficult to ignore.

Most AI decisions do not need an essay.

They need a probability.

And if a specialized model can produce those probabilities at extremely low cost and very low latency, it could change how developers design AI systems.

The question is not whether JEV will replace every LLM.

It almost certainly does not need to.

The more interesting possibility is that decision models become another standard component of the AI stack.

Not every AI problem needs a model that talks.

Sometimes it needs a model that simply decides.

Read the full article on Forg →

I shipped three updates to LogHue over the last two weeks: notes folders, public note sharing, and more flexible tasks. None of them are big on their own. But together they say something about how I'm building this product now, and it's worth writing down.

The flat list problem

Notes in LogHue used to just sit in one long list. I don't scroll through it, I search. But that only works when you know exactly what you're looking for. Glance at the list and it just looks unorganized, nothing tells you at a glance where anything is or what it belongs with.

The fix is straightforward: folders. Collapsible, so you can tuck away what you're not using. Anything you don't file stays at the top level, so nothing forces you to reorganize your whole workflow just to use the feature.

It's not a clever feature. It's just something that was genuinely missing.

Sharing without overthinking it

The second update is public note sharing. Turn it on for a note, get a link, share it. Turn it off, the link stops working and only you can see it.

I went back and forth on how complicated to make this. Access controls, expiring links, view counts. While working through it, I was told the real gap in my plan was that the link never changed once it existed. I didn't think it mattered at first. Then Claude explained properly: without a way to regenerate it, an old link stays tied to the note forever. So say you share a note with someone, later decide they shouldn't have access anymore, and turn sharing off. Then you forget you ever shared it, or you update the note with something you don't want that person to see, and turn sharing back on. The same old link still works. They can still open it.

That's the kind of gap that doesn't show up until someone's data is already exposed. So I added a regenerate button. The old link doesn't die automatically, some people will genuinely want it to keep working, but now you get the choice: regenerate it and the old one stops working, or leave it as is.

Past that, I kept the rest simple: off by default, and the whole decision lives with the person who wrote the note. If I add more later, it'll be because people actually ask for it or I actually need it myself, not because I assumed they would.

Tasks that reflect how time actually works

The third change took the longest to get right. Tasks in LogHue only ever had a deadline, a single point in time. That's fine for a to-do item. It's not fine if you want your calendar to show you when you're actually busy versus when you're free.

So, tasks can now have a start time and an end time, not just a due point. And for recurring tasks, you can choose which days reminders actually fire. Every day. Weekdays only. Weekends. Or you pick the exact days, like every Monday and Thursday.

I'd shelved this idea months ago because I assumed nobody needed it. Feedback from someone who lives in their calendar made it obvious I was wrong. The calendar is a lot more useful now that it reflects real blocks of time instead of just a scattering of deadlines.

Why this matters more than the features themselves

I use LogHue heavily myself, and it's no longer just me. Every one of these three updates still came from something that genuinely got in my way while using my own product, not from guessing what a hypothetical user might want.

It's a slower way to build. But I trust the output more, because I know exactly why each piece exists.

If you're using @loghue, I want to hear what's still getting in your way. That's the next thing I'll fix.

loghue.com

Read the full article on Forg →

AI agents burn a shocking amount of intelligence on tiny decisions.

Should I retry?
Which tool fits here?
Did this task actually finish?
Is this action risky?
Which five of these hundred documents actually matter?

Right now, most teams call the same giant model that writes their code to answer questions like these too. That's expensive, and it's overkill.

Jev fixes this. It's a small, fast model built for one job: taking a state and answering structured questions about it. No chat. No code generation. No explanations. Just decisions.

At $0.042 per million input tokens with zero output-token cost, and response times in the 70 to 500ms range, TypeSafe (the team behind it) reports workflow gains up to 193.6x faster and 444.6x cheaper than calling a frontier model for the same job.

Three question types, one call

Choice: pick one option (retry, wait, escalate).
Score: rank something on a scale (low risk to critical).
Noul: give a probability that something is true.

You can mix all three in a single request, against the same state:

{
  "state": "The deploy failed twice and customers are seeing 500 errors.",
  "questions": {
    "urgent": { "type": "noul", "instructions": "Does this need attention immediately?" },
    "severity": { "type": "score", "instructions": "How severe is the impact?" }
  }
}

Your big model keeps reasoning, writing, and researching. Jev sits around it, making the small calls that repeat thousands of times a day.

Inside the agent loop

Self-healing tool calls. An API fails. Instead of paying for another reasoning call to decide whether to retry, Jev returns retry, wait, or switch_provider directly. Your code executes it.

Loop control. "Are we done yet?" is a question every long-running agent has to answer. Feed Jev the task, recent actions, and results. It scores whether the task finished, needs another step, or needs a human.

Model routing. A typo fix doesn't need the same model as a distributed systems design. Jev decides whether the task goes to a cheap model, a frontier model, or a human, before you spend anything.

Branch pruning. When a planning model generates twenty possible approaches, Jev scores each one on cost, risk, and reversibility first. The expensive reasoning only goes to the best few.

Freedom without blind trust

This is where Jev earns its keep beyond cheap classification.

Before an agent does anything irreversible, like sending an email or issuing a refund, Jev checks: can this be undone, does it touch money or private data, is it clearly authorized. High confidence and reversible actions execute. Irreversible ones get reviewed. Unauthorized ones get blocked.

The same logic extends to temporary, task-scoped permissions instead of permanent access, and a spend firewall that reviews purchases before they happen. Indie developers stitching agents together like this, instead of just plugging into one giant permissioned model, are exactly the kind of build worth documenting somewhere. That's the gap forg.to fills: a home for builders to show what they're actually shipping, not just talk about it.

Stop paying LLMs to judge other LLMs

Using a frontier model to check another frontier model's output is expensive and slow. Jev makes the check explicit instead: did it follow instructions, are the claims supported by evidence, does it need human review. Only the uncertain cases go to an expensive judge.

The same pattern works for trace observability (did the agent loop, repeat itself, or skip an approval) and semantic code linting, where plain-English rules like "does this endpoint check authorization before touching customer data" run in CI instead of a human reading every diff.

RAG, retrieval, and research

Search returns a hundred documents. Jev scores relevance and hands your frontier model the best five. It can also verify whether a cited passage actually supports a claim, and filter stale or duplicate context before it competes for the model's attention.

Business workflows, at scale

Support routing, refund triage, lead qualification, incident response, marketplace matching, sales policy exceptions: all of these are really just a handful of small decisions repeated across thousands of cases. Jev handles the obvious ones and routes the messy ones to a human.

How to start

pip install typesafe-sdk
export TYPESAFE_API_KEY=...

Then send a state and a question. That's the whole primitive: state in, probability out, code decides.

Test it before you trust it

Don't wire this into production and hope. Pull 100 to 500 historical decisions where you already know the right answer. Run Jev against them in shadow mode, without letting it act. Compare accuracy, false positives, latency, and cost. Then set thresholds: automate above 0.95 confidence, automate-if-reversible between 0.70 and 0.95, send anything below that to a human or a bigger model.

Where Jev doesn't belong

If the task needs something created, code, content, architecture, a novel solution, that's still frontier model territory. Jev can't invent a fourth option when you gave it three. Typed outputs solve reliability. They don't solve judgment.

The bigger shift

For years, one giant model did everything: write, search, judge, route, retry, approve. That's an expensive way to run things.

The next architecture looks more like a stack: a frontier model for hard reasoning, Jev for decisions, small rerankers for retrieval, small classifiers for routing, and plain code for hard rules.

Every time you look at an agent loop now, the real question is whether that step needed a frontier model at all. Most of the time, it didn't. And if you're one of the builders putting stacks like this together, that's the kind of shipping story worth putting on forg.

Read the full article on Forg →

Indie hackers don't really have one "home" on the internet.

Some communities are built around founder stories and advice. Others are better for blunt feedback, technical discussions, audience building, accountability, or meeting other founders.

That matters because the best community for you depends on what you're actually trying to get from it.

Here are some of the most useful communities and platforms for indie hackers in 2026, what makes each one different, and where each fits into the indie-hacker ecosystem.

There isn't necessarily one platform that replaces all the others. They solve different problems.

1. Forg

Forg takes a different approach from traditional founder forums and social networks.

The basic idea is simple: your work should be part of your professional identity.

On LinkedIn, your profile is largely built around where you've worked, your education, and your job history. On Forg, the emphasis is on the things you're building, the projects you're involved in, and the people building around you.

That makes Forg feel less like a traditional career network and more like a professional network for people who make things.

Its discovery layer is also an important part of the idea. Forg Discover is designed around finding people who are building interesting things and helping those people be discovered by others.

The platform also combines several things that are normally scattered across different services:

• A profile centered around your projects and work

• Product and project discovery

• Posts and articles for sharing what you're working on

• A network of other developers, founders, designers, and builders

• Product launches and community feedback

• Distribution tools for sharing updates elsewhere

The interesting part isn't any individual feature. It's the idea of creating a professional network where what you've made is as important as where you've worked. Forg itself describes this distinction as defining people by what they build rather than their employment history.

Best for: indie hackers, developers, designers, founders, and other builders who want their projects to be part of their professional identity.

Trade-off: Forg is much newer than platforms like Reddit, X, Hacker News, and Indie Hackers, so its network and archive are still smaller.

2. Indie Hackers

Indie Hackers is one of the longest-running communities specifically built around independent businesses.

Its biggest strength is accumulated knowledge. The platform is built around founders sharing their experiences, businesses, and lessons, which makes it particularly useful when you're trying to understand how other people actually built and monetized independent products. Indie Hackers describes itself as a place where founders share their stories and where entrepreneurs can learn from those examples. It was founded in 2016.

The discussions can range from validating an idea to pricing, marketing, growth, hiring, and everything that happens after launch.

It is less about creating a polished professional identity and more about learning from the experiences of other founders.

Best for: learning from founder experiences, researching business models, and asking questions about bootstrapping.

Trade-off: the amount of historical content is a strength, but it can also make the community feel more like a forum and knowledge archive than a modern social network.

3. Reddit

Reddit is less of a single indie-hacker community and more of a collection of communities.

For example:

• r/indiehackers for indie-hacking discussions

• r/SideProject for sharing projects and getting reactions

• r/SaaS for SaaS-specific discussions

• r/buildinpublic for sharing progress publicly

That variety is Reddit's biggest advantage. You can find people interested in a very specific problem or type of product.

It also makes Reddit useful for feedback. Recent discussions from indie hackers continue to point people toward communities such as r/indiehackers, r/SideProject, and r/buildinpublic for different kinds of feedback and accountability.

The downside is that every subreddit has its own culture and rules. Self-promotion can also be heavily restricted, particularly in communities where users are already exposed to a large amount of product promotion.

Best for: getting opinions, asking specific questions, researching problems, and finding niche communities.

Trade-off: the experience varies dramatically from subreddit to subreddit, and promotional posts can easily disappear in busy communities.

4. X

X remains one of the most useful places for indie hackers who want to build an audience around themselves.

The advantage isn't really the platform's community structure. It's distribution.

Founders can share product updates, experiments, lessons, revenue milestones, opinions, failures, and launches while building a following around their work.

That makes X particularly powerful when your goal is not just to meet other founders but to become known by a larger audience.

The downside is that you're building on a fast-moving social feed. A useful post can disappear quickly, and building a meaningful audience usually requires consistent publishing rather than simply joining the platform.

Best for: audience building, distribution, networking, and personal brands.

Trade-off: reach is unpredictable, and the platform rewards people who consistently publish and participate.

5. Hacker News

Hacker News is a very different environment from the other communities on this list.

Its audience is heavily interested in technology, software, startups, and intellectually interesting projects. A successful Show HN submission can generate substantial discussion and direct feedback from technical users.

But Hacker News isn't designed to be a personal professional network or a place to maintain an ongoing creator identity.

Its own guidelines describe Show HN as a place for things you've actually made that other users can try, and explicitly discourage using the site primarily for promotion.

That culture is part of what makes useful discussions possible, but it also means a polished marketing launch isn't necessarily what the audience wants.

Best for: developer tools, technical products, open-source projects, and getting feedback from technically sophisticated users.

Trade-off: the audience is highly relevant for technical products, but the community is not designed around self-promotion or ongoing personal branding.

6. WIP

WIP is built around a much narrower idea: ship consistently.

WIP describes itself as a community of makers who ship together and help each other stay accountable. Its system revolves around sharing concrete progress rather than simply posting thoughts.

The platform is particularly interesting for people who have no shortage of ideas but struggle to keep making progress.

Instead of trying to become another giant social network, WIP focuses heavily on the habit of shipping. It includes daily progress, projects, community discussions, feedback, and regular hangouts.

Best for: accountability and maintaining a consistent shipping habit.

Trade-off: if you aren't interested in sharing regular progress, much of WIP's value proposition becomes less relevant.

7. MicroConf Connect

MicroConf Connect targets a more specific group: SaaS founders.

It is a private, vetted community for bootstrapped and mostly bootstrapped SaaS founders, with members ranging from pre-revenue founders to companies doing millions in ARR. MicroConf currently describes Connect as having 300+ bootstrapped founders.

The emphasis is less on public visibility and more on private conversations, peer relationships, advice, and accountability.

That distinction matters. Someone looking for a public place to share their new side project may get more value elsewhere. Someone trying to solve a difficult pricing, hiring, churn, or growth problem with other SaaS founders may want exactly this kind of private environment.

Best for: SaaS founders looking for deeper peer relationships and practical business advice.

Trade-off: membership is paid and curated, so it's intentionally less open than public communities.

8. Small Bets

Small Bets is centered around a different philosophy of entrepreneurship.

Rather than focusing entirely on building one large startup, Small Bets explores the idea of creating a portfolio of smaller businesses and income streams. The newsletter describes itself as inspiration for building your own portfolio of small bets.

This makes it particularly interesting for solopreneurs who don't necessarily want to follow the conventional startup path.

The community and content are less about "how do I grow my SaaS from $10k to $100k MRR?" and more about optionality, independence, and experimenting with multiple business ideas.

Best for: solopreneurs interested in small businesses, digital products, and entrepreneurial optionality.

Trade-off: the philosophy won't appeal to someone whose primary goal is building one large venture-backed or bootstrapped company.

How these communities fit together

The useful thing about these platforms is that they don't actually need to compete for exactly the same job.

You might use:

• Indie Hackers to learn from other founders.

• Reddit when you need feedback or want to find a niche community.

• X when you want distribution and an audience.

• Hacker News when you've built something technical that developers can actually try.

• WIP when accountability is your biggest problem.

• MicroConf Connect when you want deeper conversations with SaaS founders.

• Small Bets when you're interested in building multiple small businesses.

• Forg when you want your projects and what you build to become part of your professional identity and network.

That's probably the most important distinction.

The indie-hacker ecosystem isn't really one giant community. It's a collection of different places for different stages of building.

And the interesting question isn't necessarily "Which community is the best?"

It's "Where do you want your work to live?"

Read the full article on Forg →

It's 1:40 a.m. The fan is on its slowest setting, the coffee went cold two hours ago, and the only light in the room comes from a laptop screen. On that screen is a notification nobody else in the house would care about:

New payment received: $9.

The person staring at it has no funding round, no board of directors, and no office with a ping-pong table that nobody uses. What they do have is a product they built alone, a few dozen users who found it through a forum comment, and now, somehow, a stranger willing to pay for it.

That person is an indie hacker. And if the moment sounds small, you probably haven't met one yet.

The short answer

An indie hacker is someone who builds a business on their own terms. Usually small, usually online, and almost always without outside investors.

"Indie" means independent. "Hacker" doesn't mean someone breaking into bank servers from a dark basement. It's the older, kinder meaning of the word: a person who figures things out with whatever tools happen to be lying around.

Indie hackers build SaaS tools, browser extensions, newsletters, templates, mobile apps, APIs, and oddly specific marketplaces that serve exactly one type of customer very well. Some make enough for a weekend dinner. Some replace their salaries. A few build something big enough that investors start calling, and then politely decline the meeting.

The size of the business isn't what makes someone an indie hacker. Ownership is.

Meet Ananya

Let's go back to our 1:40 a.m. builder. We'll call her Ananya.

Ananya is a freelance designer. For three years, every new client meant the same ritual: copy last month's invoice spreadsheet, fix the formulas she broke last time, chase payments over email, and repeat. One evening, annoyed for roughly the four-hundredth time, she thought, someone should just build a simple tool for this.

Then came the thought that separates indie hackers from everyone else: why not me?

She didn't write a business plan. She didn't make a pitch deck. She spent six weekends building the smallest possible version of an invoicing tool for freelancers. It had one feature that worked and two that mostly worked. The landing page had a typo in the headline for eleven days.

She shipped it anyway.

The loop that runs everything

If you watch enough indie hackers, you start to see the same pattern. It goes something like this:

Notice a problem that annoys real people. Build the smallest thing that solves it. Put it out into the world before it feels ready. Talk to the people who use it. Fix what they complain about. Repeat until something clicks, or until you learn enough to start the next thing.

That's it. No secret framework. The magic isn't in the loop itself. It's in how many times someone is willing to run it.

Ananya's first version got 14 signups in a week. Nine of them never came back. Three sent feedback. One of those three said, "I'd pay for this if it sent automatic payment reminders." So she built payment reminders.

That's how the $9 happened.

What indie hackers have in common

They wear every hat. On any given day, an indie hacker is the developer, the designer, the support team, the marketing department, and the accountant who quietly panics at tax time. There's no one to hand things off to, so they learn a little of everything and get surprisingly good at a few things.

They prefer profit over valuation. A startup might chase growth and worry about money later. An indie hacker usually wants the business to pay for itself as early as possible, because there's no investor cushion to fall back on. Revenue isn't a vanity metric for them. It's oxygen.

They ship before they're comfortable. Perfection is expensive when you're a team of one. Indie hackers learn early that a working product with rough edges beats a flawless product that only exists in a Figma file.

They build in public. Many of them share their revenue numbers, failed launches, half-finished features, and lessons learned, openly and in real time. It sounds risky, but it does two things at once: it keeps them accountable, and it quietly builds an audience of people rooting for them.

And more than anything, they want freedom. Freedom to choose what to work on, who to work with, and when to close the laptop. Money matters, but control over their own time is usually the real prize.

The awkward question: where do you show your work?

Here's a problem Ananya ran into a few months in.

She wanted to share her progress. Every new feature, every small milestone, every "we crossed 100 users" moment. But most professional networks weren't built for someone like her. Her feed was full of people who were "thrilled to announce" promotions, and her profile asked for job titles and employment history. The honest version of an indie hacker's résumé is a list of side projects that didn't work, followed by one that finally did. That doesn't fit neatly into a box labeled "Experience."

Regular social media wasn't much better. She'd write a thoughtful update about a feature she'd spent two weeks on, and it would disappear from everyone's feed in twenty minutes.

Eventually a fellow founder pointed her to forg.to, and it clicked, because it's built around a simple idea: your identity is what you build, not where you've worked.

Her profile there isn't a résumé. It's her product, her stack, and her entire build history in one place. Every update she ships lands on a timeline, so her product's story grows chapter by chapter instead of vanishing after launch day. Shipping streaks show that she actually builds, consistently, which is the kind of proof no job title can offer. When she launched a new version, she put it on the Monday Launchpad and got feedback from other founders who ship things themselves, not from bots or people who just drop a thumbs-up and leave.

And the part she loved most: she writes an update once and cross-posts it to X, LinkedIn, and Bluesky with one click. No more rewriting the same announcement three times.

It feels less like a corporate networking event and more like a room full of people with laptops open, trading notes on what they're building. No corporate slop. Just work, shown honestly.

A few myths worth clearing up

"You have to be a programmer." You don't. Plenty of indie hackers build with no-code tools, sell digital products, run newsletters, or team up with a developer friend. The "hacker" part is about resourcefulness, not syntax.

"It's just a side hustle." Sometimes it starts that way, and sometimes it stays that way by choice. But many indie hackers eventually go full-time on their products. The difference isn't in how serious the work is. It's in who owns it.

"You have to do it all alone." Indie means independent, not isolated. The best indie hackers are deeply connected to other builders. They swap advice, test each other's products, share launch strategies, and cheer when someone hits their first dollar. Working alone doesn't have to mean being lonely.

"If it doesn't become huge, it failed." A product that pays your rent, runs on a few hours a week, and serves customers who genuinely love it is not a failure. For many indie hackers, that is the entire dream.

Back to 1:40 a.m.

Ananya didn't sleep much that night. Before closing her laptop, she posted a short update on her Forg timeline:

"First paying customer. $9. Going to bed at 3 a.m. Worth it."

By morning, a dozen founders had replied. Someone congratulated her. Someone asked how she handled payment reminders. Someone else shared the story of their own first $9, which had happened four years earlier and had since turned into a business that paid their whole team.

That's the thing about indie hackers. The first dollar is never really about the dollar. It's proof that something you made, by yourself, from nothing but an annoyance and a few stubborn weekends, is valuable to someone else.

So, what is an indie hacker?

It's anyone who has ever looked at a problem and thought, why not me? And then, instead of waiting for permission, opened their laptop and started building.

If that sounds like you, you're already one. You might as well start showing your work.

Read the full article on Forg →

Reasoning scores keep climbing while per-token compute keeps falling. GLM-5.2 scores 99.2% on AIME 2026 with about 40 billion parameters active per token. Qwen3.5 hits 91.3% with 17 billion active. DeepSeek V4-Flash runs 13 billion active. For scale, GPT-4 was rumored to run around 280 billion active parameters in 2023, and it could barely finish an AIME problem. At the small end, Qwen3.5 9B fits in 6GB of VRAM quantized and roughly doubles the score of the next best model under 10B on Artificial Analysis's intelligence index.

Look only at math and code and you would conclude that intelligence per parameter is improving at an absurd rate.

Now ask the same models a plain factual question. On SimpleQA, closed book with no tools, the current leader is Gemini 2.5 Pro at 53%. The best factual recall money can buy still misses half the questions. The small models barely register: Artificial Analysis measures Qwen3.5 4B and 9B at hallucination rates of 80 to 82% on its knowledge benchmark. When they don't know a fact, which is most of the time, they invent one. Ask the 9B for the birth year of a minor 19th-century mathematician and you get a confident, plausible, wrong answer.

The parameter count didn't drop for free. Labs are trading world knowledge for reasoning skill, and the trade is deliberate.

What the parameters were for

Facts take space. The cleanest measurements I know of come from the Physics of Language Models series, which puts the ceiling at roughly two bits of factual knowledge per parameter. If you want a model that knows the birth year of every minor Wikipedia figure, the population of every Dutch municipality, and the argument order of every function in every npm package, you pay for that in weights. That is a large part of why frontier models grew into the trillions.

Reasoning compresses much better, because it is a small set of procedures applied over and over: split the problem, track intermediate state, check your own work, backtrack when a step fails. Distillation and reinforcement learning on verifiable tasks transfer those procedures into small models surprisingly well. Phi-4 is 14 billion parameters, trained heavily on synthetic textbook-style data, and it is good at math and bad at trivia. That tells you exactly what was in its training set. Two years ago that profile read as a limitation of synthetic data. Now it reads as the spec.

The knowledge that survives the trade has a shape worth noticing. These models are generalists: a little about nearly everything, almost nothing in depth. Ask one about PostgreSQL and it knows what it is, what it is good at, and roughly how MVCC works. Ask which version added a specific planner feature and you are back to invented facts.

I think that is the correct layer to keep in weights. Breadth is what lets a model understand what a question is about, know what to go look up, and judge whether a source is plausible. Depth is cheap to retrieve and expensive to store, so depth is the part that goes.

Facts rot, procedures don't

A frontier training run takes months and costs hundreds of millions of dollars, and the facts inside it start going stale the moment it finishes. APIs change, prices change, people change jobs. Half of what a 2024 model believed about the JavaScript ecosystem was already wrong on release day. Every fact baked into weights has a shelf life, and the only refresh mechanism is another training run.

Procedures don't rot. Algebra worked the same way in 1970. So did breaking a problem into parts, or spotting a contradiction between two sources. A model that is mostly procedure and only lightly loaded with facts does not age the way a knowledge-heavy model does. Its training cutoff matters much less, because the current state of the world was never supposed to live in the weights.

This is the strongest argument for the whole approach, and it is the one that convinced me. It decouples the expensive, slow artifact from the thing that changes daily.

The harness carries the knowledge

If the model doesn't know things, something else has to. That something is the harness: retrieval over a knowledge base, tool calls, web search, a filesystem full of docs. I wrote earlier that Rust is a harness for agents, a source of cheap machine-checkable feedback. This is the same shape viewed from the other side. The model supplies reasoning. Everything it reasons about gets supplied at runtime.

You can already watch agents work this way. A coding agent does not need your dependency's API surface memorized, because it greps node_modules or reads the docs before it calls anything. Its answer is grounded in the version you actually have installed, not whichever version dominated the training corpus. Recall that used to be a fixed cost in every forward pass became an on-demand lookup.

Knowing less only helps if the model knows that it doesn't know

This is the part I think most of the optimistic writing on this skips, including my own earlier drafts.

A small model paired with a good harness is only safe if it reliably says "I don't have this, let me look it up." Abstention is not a free side effect of having fewer parameters. It is a separate trained behavior, and the industry has spent years training the opposite.

OpenAI's 2025 paper on hallucination makes the mechanism plain: most benchmarks use binary scoring, so a wrong answer and an abstention score identically at zero. Under those rules a model that always guesses beats an otherwise identical model that sometimes admits uncertainty. We built the leaderboards to reward bluffing and then acted surprised when models bluff.

Shrinking the model makes this worse before it makes it better, because you have widened the gap between what the model is asked and what it holds. Those 80% hallucination rates on small models are not a knowledge problem. They are a calibration problem sitting on top of a knowledge problem. The knowledge half is the part we are deliberately removing. The calibration half is the part that has to be solved, and it does not get solved by making the model smaller.

A frontier model on your GPU

Follow the trend out a couple of years and I think you get frontier-quality reasoning on a single consumer GPU.

The compute half is close. DeepSeek V4-Flash reasons with about 13 billion active parameters per token, comfortably inside consumer range. What does not fit is the other 271 billion sitting in its experts. Note that this is a memory problem, not a compute problem: in a mixture of experts you only multiply through a slice of the weights per token, but the whole thing still has to be resident somewhere the GPU can reach. Active parameters set your speed. Total parameters set whether you can run it at all.

Expert layers are mostly fact storage, and fact storage is exactly what this trade makes optional. Strip it out and total size collapses toward active size. A 20 to 40B model at 4-bit quantization fits on the 24GB card that has been sitting in gaming PCs since 2022.

The catch is that it will not know much. Asked a bare factual question with no tools attached, the correct behavior is to say so and go look. Paired with a decent harness, that covers most of what I use a frontier model for today, running locally, with no per-token bill and nothing leaving the machine.

Where this breaks

Two honest problems, since I would rather state them than have them stated back to me.

First, retrieval is not free. Every fact that used to be one forward pass away is now a round trip and a few thousand tokens of context. You have not eliminated the cost of knowledge, you have moved it from weights into the context window, where it is paid again on every single query instead of once at training time. For a local model with no per-token bill that is a good trade. For a high-volume API workload it is much less obviously one.

Second, judgment needs a floor of knowledge. To evaluate a retrieved document you need enough background to tell a good source from a bad one, and to notice when a question contains a false premise you need to already know the thing being assumed. Cut too deep and you get a model that reasons beautifully over whatever garbage the retriever handed it. Nobody has published a clean number for where that floor sits, and I suspect it is task-dependent enough that nobody will.

This mostly fixes hallucination

Still, the direction is right, and the reason is what it does to wrong answers.

When a fact lives in weights, a wrong fact is unfindable and unfixable. You cannot grep the weights, you cannot diff them against last month, and correcting one error means a fine-tune that might break who knows what else. The model states a wrong fact with the same fluent confidence as a right one, and there is no artifact to check it against.

When the fact lives outside the model, a wrong answer has an address. The model cites a document, so you open the document. If the document is wrong you edit it, and every future query gets the correction instead of waiting a year for the next training run. Retrieval does not get you to zero, since a model can still misread a source or stitch two together wrong. But a claim with a source is checkable and a claim from weights is not. A wrong fact in a knowledge base is an ordinary data bug, the kind we already know how to trace, fix, and write a regression test for.

There is a version of this where the model card stops listing a knowledge cutoff entirely, because what is left in the weights goes stale on a scale of years instead of weeks. The model just gets handed the current state of the world at runtime, the way a CPU gets handed a program.

Read the full article on Forg →

I pulled the numbers from Forg across 700 public projects, 1.5k+ builders, and a mountain of company data to answer three questions I keep arguing about with other founders:

1. What are indie hackers actually shipping?

2. What stack are they running?

3. How are they charging for it?

The patterns turned out sharper than I expected. Here's the honest read.

AI didn't win. It lapped the field.

"AI is popular" is not news. What surprised me was the margin.

AI is the single most common project tag, and if you group the whole family together (AI, AI Agents, AI Tools, AI Video Generators) it accounts for 8.5% of every tag on the platform. No other theme comes close.

But the tag counts undersell it. The growth curve is the real story.

In the last six months, AI jumped from 5 projects to 28, a +460% increase. SaaS grew from 5 to 18 projects, up +260%. But the more striking finding is that entire categories appeared from nowhere. "AI Agents" went from zero projects to thirteen in a single six-month window. AI Video Generators, Privacy, and Marketing tools didn't exist as meaningful categories here six months ago. Now they do.

Builders are skilling up to match. LLMs, RAG, LangChain, the OpenAI API, and prompt engineering are all showing up on profiles now. It's still a minority cohort, around 2.8% of users, but it's the fastest-forming one on the platform.

Takeaway: If you're starting something today, "AI-native" isn't an edge anymore. It's the baseline everyone else is already at.

There is now one indie hacker stack, and it's frontend-first

Ask ten founders their stack and you used to get ten answers. Not anymore. The skill data has quietly converged on a single, boring, effective setup.

Product Design tops the list with 55 builders claiming it, followed by JavaScript (52), TypeScript (49), React.js (48), and Figma (45). After that comes Python (22), PostgreSQL (18), Node.js (13), and Next.js (12).

Two things jump out immediately.

First, design is not a nice-to-have. Product Design is the number one skill, and Figma outranks Python. The modern solo builder is expected to make it look good, not just make it work.

Second, TypeScript is nearly caught up with JavaScript (49 vs 52) and growing faster in project tags. If you're picking one to invest in deeply, the trend line points clearly at TS.

The full picture: JavaScript + TypeScript + React + Next.js + Figma + a Postgres backend. That's the default kit now.

Everyone charges the same way: free (at first)

This one is almost unanimous. Freemium is 73% of all projects. Add straight-up free products and 88.5% of projects have a free entry point. Subscription-only accounts for just 8%, and one-time purchase sits at a mere 3.7%.

The free-door funnel has become the reflex. Which is exactly why the opposite is interesting. One-time pricing has been nearly abandoned. In a world where everyone is training users to expect a free tier, "pay once, own it forever" is starting to look like a differentiator rather than a mistake.

Still web-first, and it's not close

For all the mobile hype, the platform is overwhelmingly built for the browser. Web accounts for 77% of all projects. Mobile (iOS and Android combined) makes up 17%. SaaS is 47% of all product types, with mobile apps at 21%.

The playbook most builders are running is to ship web first and add mobile only if traction demands it. Cross-platform combos exist, like Web plus Chrome Extension for automation tools or iOS plus Android for social apps, but they're the exception, not the plan.

The gaps nobody is filling

The most useful part of any trends report isn't what's crowded. It's what's empty.

A few categories are almost untouched. Testing and QA has just 3 projects. IoT and hardware has 1. Crypto payments has 1. Firefox extensions have 4. APIs sold as a standalone product account for only 15 projects. And as mentioned above, one-time pricing covers just 3.7% of the market.

None of these are glamorous. That's the point. Everyone is piling into AI-flavored freemium web SaaS, which means the whitespace has moved to the unsexy corners: developer tooling, hardware, and business models that don't start with "free."

So what should you build?

The safe bet, statistically, is an AI-enhanced, freemium, web-first SaaS built on TypeScript, React, and Next.js, with a designer's eye on the UI. Do that and you'll fit right in.

But "fit right in" is another way of saying "crowded." The more interesting move is to take the modern stack everyone has converged on and point it at a corner nobody is serving: testing, hardware, a genuinely great Firefox tool, or a premium product you pay for once.

A caveat worth stating: this is a snapshot of one platform, and skills are self-reported. Treat it as a strong signal about where indie builders are heading, not gospel. But the direction is hard to miss. AI is up and to the right, design is on equal footing with code, and free is the default front door.

What are you building right now, and does it match the pattern or break it? I'd genuinely like to know.

PS - The research is done only on the data of forg.to users and projects not globally.

Read the full article on Forg →

You pour your heart into an idea. You spend days or even months designing, building, debugging, and polishing every little detail. Throughout the process, you're convinced this could be the project that changes everything. The one that finally takes off. The one that brings users, income, recognition, or whatever you're chasing.

Then launch day arrives.

You hit "publish" and wait.

Hours pass. Then days.

Nothing.

Nobody signs up. Nobody talks about it. Nobody seems to need what you built.

That's when reality hits. It feels like all those weeks or months were wasted. You start questioning yourself and wondering whether it's even worth building anything anymore.

I've felt that before.

But I didn't give up.

I've realized that even when a project doesn't attract users, it still gives me something valuable: experience. I never build the same thing twice or stay inside my comfort zone. Every new project pushes me to learn something I've never done before, whether it's a new technology, a different way of solving problems, or a better approach to designing products.

Because of that, I don't see these projects as failures. I see them as investments in my skills.

Would I rather have users? Of course.

Would I rather see my work make an impact? Absolutely.

But I'll always keep building, keep learning, and keep improving. Every project makes me a better developer than I was before, and eventually those lessons will add up.

Maybe the product fails.

But if you become better because you built it, then your time wasn't wasted.

Read the full article on Forg →

Nine devices, two builders, and a system that needs to work when someone outside Copy designs the next one.

Originally published on Minimum Viable Thoughts, with the full set of images and video clips.

Copy is an async walkie-talkie app my friend Matt Moss and I are building. Hold push-to-talk, speak, and let go. Your friends listen whenever they’re ready. You start by picking the device you want to hold.

The system behind those devices has carried nine of them so far, built by two people with different processes, and it’s about to start taking designs from other designers and builders.

Each device has its own design, motion, sounds, and haptics. Underneath, every device has to handle the same friends, channels, messages, errors, settings, and gestures.

Copy is meant to feel like a real device. That was one of the early design constraints Matt and I set. Every time we hit a UX question (settings, pairing, dark mode, empty states) the answer was the same: what would this look like on a physical device?

That constraint made Copy easier to design but it also multiplied the work. Every new device had to carry every state, every color, and every mode on its own.

So the challenge was deciding what Copy handles once, and what each device is allowed to break.

Four jobs underneath every device

I designed the first four devices in Figma, then built them in React Native with Claude and Codex. I knew we wanted to keep making more device skins, so as I built I started mapping out the shared jobs every device would need.

As I found them, I wrote the decisions into a theming guide inside the repo. THEMING.md became the place Matt, the coding tools, and I could all check how a device should work.

At the top of each device is a decoration area, which also carries the device’s settings control. On WT-01 that means speaker holes and a physical settings button. On Interlinked it means moving graphs and a small control inside the display.

Below that is a channel plate. It has to show who you are talking to and what’s happening: a message playing, a friend joining, a recording being sent, or an error.

Then the channel selector and the push-to-talk button. You pick a friend, hold the button, talk, and let go to send.

Those were the four initial shared jobs: decoration, channel plate, channel selector, and push-to-talk. As Copy grew, the same system expanded to cover sound, haptics, lighting, color, accessibility, and every state the device has to display.

WT-01 is our homage to Teenage Engineering. Clean chrome, sharp lighting, little speaker holes at the top. The channel selector needed to feel like a real knurled knob you could turn. The LCD sits inset in the body. The settings button and push-to-talk button look like physical controls you could actually press.

Interlinked is more sci-fi meant to feel like something you’d see in Blade Runner. Moving graphs, a rangefinder-style channel selector, more screen than hardware.

Rams asked what a walkie-talkie would have looked like if Dieter Rams designed one. It keeps the physical-radio language, with a rotary dial and a small indented push-to-talk button.

Goto pulled from Teiyu Goto’s PlayStation-era work. A memory-card grid sits inside the channel plate, with a D-pad below it for moving through channels. It still feels like a device you’re holding, just from a completely different family of hardware.

Copy is on the App Store if you want to hold one of the devices in hand while you read.

What the device decides

Finding the four shared jobs was the first part to figure out. The next was drawing a clear line between what a device author needs to decide and what Copy handles.

A device defines its visual identity. Copy handles the product behavior underneath it.

That line lives in the theming guide because people and AI coding tools both use it. Before a new device is built, the guide asks two questions.

Is its body a physical object or a digital display? A physical device gets hardware-like lights and controls. A display can change its on-screen elements without breaking the illusion.

Does color tint one base device or repaint the full palette? A tint device gets the shared lighting and color layers. A palette device supplies a complete set of colors for each treatment.

Those answers connect the device to the right parts of Copy. Every channel plate gets the same product states, messages, and accessibility labels. Tint devices get the same color and lighting math. The designer decides how all of that looks and feels on the device.

Turn the channel selector on any device and it drags, clicks, and snaps to the channel the same way every time. The knurled knob on WT-01, the smooth rotary on Rams, and Ghostline’s frequency dial look nothing alike but underneath they behave identically.

Each device uses a set of shared components. When a design needs something outside that component list, I stop and see if that capability should be a part of Copy. If it does, I build it once and add it to the shared system.

Here’s the split, condensed out of THEMING.md

Declare intent, not behavior.
A skin defines a visual identity. Shared behavior lives in
shared primitives the skin opts into based on what you declared.

You specify Copy handles
Theme tokens - Channel plate state derivation
Component implementations - Shared-state accessibility labels
At least four treatments - Rotary drag, snap, wraparound
Light/dark behavior - Color and lighting math, if you tint

Writing the rules down also changed how the coding tools worked. My coding agent kept simulating shadows because it thought I had an older version of React Native that couldn’t draw complex shadows. Once I figured out it was approximating instead of being exact, I wrote the rule down:

THEMING.md
React Native 0.76+ on the New Architecture supports CSS-like boxShadow. Use it directly instead of the legacy shadow properties.

This is essential for neumorphic/skeuomorphic skins like WT-01, Rams, Goto etc.

boxShadow: "1.692px 1.692px 8.462px 0px rgba(49,51,62,0.81),
-1.128px -1.128px 8.462px 2.256px #FFF"

No external libraries needed. Copy shadow values directly
from Figma's CSS output.

New behavior has a path too. It gets added to the checklist and to the examples that power our tests and review gallery. The current test suite opens every registered device in every channel and push-to-talk state. It catches crashes and helps us spot missing shared behavior across the other devices while we are working on one. We also have a dev mode that lets us look through the same cases to test them visually.

That lets the shared product keep changing while each device keeps its own design language.

The structure can bend

Watch clip 1 in the original article.

Goto bends the rules twice. The memory-card grid in its channel plate is itself a channel selector, and the D-pad below it is a second one. Two visible ways to move through channels, both wired to the same underlying job. The system has a defined place for that override, so Goto gets its second selector without Copy needing to carry a special case.

Poolside came next, the first device I built completely in code. It keeps all four jobs, with its speaker as the decoration up top, but the two main controls sit side by side. Heavy gradients give the whole thing an 80s Miami feel.

Flux uses a dial to change channels, but the rest of the device goes in a very different sci-fi direction. Its selector holds a floating icosahedron that grows and warps while you talk.

Interlinked, Goto, Poolside, and Flux all keep the same channels and push-to-talk behavior while arranging the controls differently and using their own visual language.

Every part of Copy had to belong to the device

The four initial jobs handled the main components, but there’s so much more that makes up a Copy device. Over time, we needed sound, haptics, settings, pairing, error and empty states that all had to follow the same device rule.

The first settings control was a little icon floating in the corner. It worked, but it felt bad. You were supposed to be holding WT-01 in your hand, and a flat app icon was sitting on top of it.

I went back into Figma and designed a control for each device. On WT-01 it became a physical button you could press. On Flux it became the sys.cfg control inside the display. Both open the same settings, but each one belongs to the thing you’re holding. This became a new rule in THEMING.md: every device needs a settings control that matches its design.

Errors followed the same rule. When we needed error messages, the standard app answers were toasts and pop-ups. We didn’t want an app pattern sitting on top of the device. So errors show up on the channel plate, through the device’s own display, the way a real device tells you something went wrong.

Once you have Copy installed, you need to pair it with a friend before you can talk. The original version of pairing was a QR code you could scan or a code to type in. The camera and code-entry screen pulled you away from the walkie-talkie, so Matt and I moved the invite into iMessage. You send someone a link and the pairing happens behind the scenes.

Matt pushed it further while we were working on pairing. He moved the friend confirmation out of an overlay and onto the channel plate itself. The device just tells you in the channel plate when someone connects instead of it being an overlay or a toast.

Empty channels needed their own treatment too. WT-01 lights up ridges around the dial. Rams uses glowing channel numbers. Goto puts plus signs into its memory-card save slots. Interlinked uses open circles in the rangefinder. Same empty-channel state, drawn four different ways that fit the hardware.

The physical rule also shaped sound and haptics. WT-01’s dial snaps as you turn it. The push-to-talk button moves when you press down. The devices react to your voice differently too. WT-01 has a waveform. Goto uses scanlines. Flux’s icosahedron grows and changes shape while you talk.

You turn something, feel it click, press the button, and see the device respond to your voice.

Designing each device once

After the first four devices, some of our early testers were asking for dark mode. Color options were coming right behind it. One base design needed to carry all of those combinations.

Because the devices are meant to feel physical, I treated dark mode as lighting. It needed to feel like the light in the room had changed. A Braun radio doesn’t become a different radio at night. You’re holding the same object in a darker room.

I started by changing each device by hand in Figma. I adjusted the shadows and added a soft glow to the channel plate. It looked right, but every new device would need another night pass. Then another pass for every color.

So the lighting became a layer over the same materials and controls.

Color works the same way for some devices. WT-01, Rams, Goto, and Poolside use a tint over one base design: the dimensions, type, materials, and shadows stay the same while a color layer changes the cast of the device, and the night lighting rides on top as its own layer. The system checks how dark the tinted body would become. If the color and night layers together would make the controls hard to read, it backs off the tint.

Other devices swap their complete palettes instead. Flux, Interlinked, and End of Line each supply a full set of colors for every treatment. The product behavior stays put, but every surface can take on a different color.

Light and dark mode are separate from color. Interlinked is a dark cyberpunk display, so it stays dark in both modes.

The same system tints WT-01, repaints Flux, and leaves Interlinked dark. Those choices are set once for each device, then reused across its screens and states.

Two co-builders, different processes

Next, Matt and I worked on two devices around the same time. I built Poolside. Matt built End of Line.

Matt didn’t use Figma. He made mockups in code first, then brought the device into the same shared structure.

End of Line has a draggable light-trail channel selector, an identity-disc push-to-talk button, moving circuits, its own voice-reactive display, and a full set of sounds. Its color options repaint the whole device instead of tinting one base design.

It looks like Matt’s work because it is. The system gave both of us the same channels, messages, errors, and gestures without asking us to use the same design process. Matt got room to work in HTML instead of Figma and arrive at his own visual answer. I built Poolside in code. Matt built End of Line in code. Both still felt like Copy.

Matt came back to the same structure for RX-80, a handheld device in gunmetal with a machined deck and a larger channel plate LCD. Instead of a dial, it has a roller you spin to change channels and a mini LCD that shows channel status like joining a channel and sending.

That’s two devices Matt designed his own way, both running on the shared system without Copy carrying a special case for either one.

Opening Copy to other creators

Matt and I have always wanted to open Copy up to other creators. The old Winamp days are the reference, when people made their own skins and changed how the software looked. We want Copy to have some of that same energy.

For that to happen, bringing a new design into Copy has to be something anyone can do. Right now that takes Matt or me. I’m building a process that takes a design made in code and brings it into Copy with the product behavior already connected.

Ghostline was the first full test of the new import process.

It started as an unfinished tactical radio prototype I made in Claude Design. The pipeline keeps that original design untouched and hands my coding tools the source next to the rules I’ve already written in the theming guide, then asks them to map one to the other. Anything unclear stops and waits for my call.

That run exposed where the process still relied on Matt or me knowing what to check. The existing devices already handled rotary alignment, snapping, haptics, and message lights, but a new import could still miss them without the process stopping it. I built shared components for new imports, added those behaviors to the checks, and ran it again.

By the final pass, most of Copy’s behavior came through in one shot. The slate body, frequency dial, screen, and recessed push-to-talk button carried over from the original design. The dial became Copy’s 12-channel selector with the shared snapping, haptics, sounds, and accessibility already working.

Ghostline still took far less time than the earlier devices. The shared system already handled the product behavior and had tests covering it, so I spent my time on how the device looked and felt instead of checking every message and error state by hand.

Watch clip 2 in the original article.

Ghostline will be releasing soon in the next App Store build.

Next, I want the same process to work with a design straight from Figma.

After that, Matt and I want to open it to designers and builders outside Copy. You’d get to design an entire device: its controls, display, color, motion, and sound. The shared system handles Copy underneath it, so your time goes into making the device feel like yours.

The first authors will be people comfortable in Figma, prototyping in code or both. Matt and I will help you get the skin ready to ship in Copy.

We’re still working out the exact business model, but we absolutely want creators to get paid for their work.

Want to make one?

Join the waitlist to make a skin for Copy

Download Copy to try the devices yourself.

Read the full article on Forg →

How forg.to Got Cited by ChatGPT Before It Ranked on Google

I opened Ahrefs a few weeks ago to check one number. Forg's domain rating: 43.

For something built mostly in evenings, that felt like a milestone. Google was starting to trust the site enough to rank it.

Then I checked something else, almost by accident.

Referral traffic from ChatGPT.

Not a fluke, not a one-time spike. Repeated visits, day after day, coming from people who had just asked ChatGPT about indie builders, side projects, or companies they were curious about. ChatGPT was answering with forg.to as the source.

I sat with that for a minute. We had a real, measurable footprint in search engines that don't rank pages at all. They answer questions.

Two different games, two different timelines

Google ranking is slow by design. It rewards backlinks, domain age, consistent traffic, months of signal stacking on top of each other. Hitting a DR of 43 took real time.

AI citation doesn't work like that. ChatGPT, Perplexity, and tools like them aren't ranking pages against each other. They're pulling a structured, unambiguous answer to a specific question and deciding, in that moment, whether your page is clean enough to hand to someone as the answer.

That's a completely different bar to clear. Turns out we'd been clearing it without fully realizing.

What actually made this happen

Looking back, three things mattered more than anything else.

We made the site easy to parse, not just easy to read. Every builder and product page on Forg has a markdown mirror sitting next to the regular page, plus schema.org structured data describing exactly what it is. Humans never see this layer. Models read it directly.

We picked one identity and never let go of it. Forg is a builder identity network. Not a portfolio tool, not a launch platform, not build-in-public with a new coat of paint. Every page, every bio, every description repeats that same framing. AI models seem to reward that kind of consistency, because ambiguity is exactly what makes a source unreliable to cite.

We fixed our own confusion before it could confuse anyone else. There's a publicly traded company with a similar-sounding name. Early on, we deliberately disambiguated Forg from it across every page and every piece of structured data. A model that can't tell what you are won't risk citing you.

None of this was a growth hack. It was closer to good writing discipline, applied at the infrastructure level instead of the sentence level.

The part that actually matters

A lot of builders I know are shipping genuinely good work right now. If someone asks an AI about them today, there's a real chance the AI has nothing to say back. Not because the work isn't good. Because there's no clean, structured place for the model to find it.

Google used to be the only front door to being found online. That's no longer true. There's a second door now, and it opens on different rules: clarity over authority, structure over age, a clean answer over a large backlink profile.

We didn't plan for Forg to become an example of this. We were just trying to build something honest for builders. It turned out honesty, structured well, reads as trustworthy to a model too.

The window to be the answer, and not just a listing, is still wide open. Most people building things right now don't know it exists.

Read the full article on Forg →

LinkedIn Feels Like Facebook Now. Here's What Comes Next. #career #developers #discuss #design

Open LinkedIn. Then open Instagram. Then go back to LinkedIn.

You will feel the fifteen years. The blue-and-white template. The dense wall of text posts stacked on top of each other. The same "3rd" badge next to every name. The same grey card shadows that haven't changed since profile redesigns were still called "beta." It is functional in the way a government form is functional. Nobody opens it because they want to. They open it because they feel they have to.

Now scroll Instagram. Or Arc. Or Linear's website. Or basically any product built in the last five years by people who cared about how it feels to use. Dark, considered interfaces. Whitespace that isn't accidental. Content that is the product, not decoration bolted onto a spreadsheet.

The short answer to "what's the best LinkedIn alternative in 2026" is this: builders aren't looking for another feed. They're looking for a professional network that was actually designed, built for a narrower audience, and not drowning in AI-written filler. That's the gap forg.to is built to close. Design is the first thing you notice. It's not the main reason people stay.

LinkedIn Is the Facebook of Professional Networks

Facebook's core layout hasn't fundamentally changed in over a decade. A vertical feed of text and photos from people you loosely know, interrupted by ads, sorted by an algorithm you don't control, wrapped in a blue-and-white shell that was already starting to look dated by 2015.

LinkedIn is that same shape, just wearing a suit.

A vertical feed. Text posts from people you loosely know. Ads wedged in every few scrolls. A notification bell that never stops lighting up for things that don't matter. The profile page is a form: job title, company, dates, a skills list nobody verifies. It was designed for résumés on the internet, and it still looks and behaves like a résumé on the internet, even now that "professional identity" means something much bigger than an employment timeline.

Instagram, by contrast, rebuilt the idea of a profile around the content itself. Your grid is your work. Your Story is your update. The design gets out of the way so the thing you made is what people actually see.

That's the model forg.to follows for professional identity: the product, the update, the shipped feature is the profile. Not a résumé with a photo attached to it.

The Feed Is Drowning in AI Slop, and the Data Backs It Up

This isn't a vibe. It's now measurable.

A July 2026 study from AI detection firm Pangram Labs analyzed over a million posts across six major platforms — LinkedIn, X, Substack, Medium, and Reddit among them. The result: more than 40% of LinkedIn's long-form posts were flagged as fully AI-generated, the highest share of any platform measured. LinkedIn alone accounted for roughly two-thirds of all AI-generated content Pangram detected across every platform in the study, even though its posts made up only about a third of the total sample.

It gets more specific. Pangram found that LinkedIn users tend to go all-or-nothing with AI — only about 4% of flagged content was AI-assisted or lightly edited. The rest was either fully human or fully machine, meaning the platform isn't full of people polishing their own drafts with AI. It's full of people outsourcing the writing entirely, then hitting publish under their own name and photo.

The market has already started punishing it. Coverage of the same study found AI-generated LinkedIn posts pulling in roughly 45% less engagement than human-written ones. Readers can tell, even when they can't articulate why. And LinkedIn's own reported content volume kept climbing anyway, up 14% year over year as of mid-2026, which means the flood isn't slowing down.

So the platform where career reputations are supposedly built on visible expertise is now a place where the majority-vote experience is: is this even a person?

LinkedIn Is for Everyone. That's the Problem.

LinkedIn's pitch has always been breadth: every industry, every job title, every professional on one network. A nurse, an insurance broker, an HR manager, a real estate agent, a Fortune 500 SVP, and a first-year developer are all sharing the same feed, the same algorithm, and the same incentive to sound impressive.

That breadth is exactly why the feed reads the way it does. A platform trying to serve every profession on earth ends up optimizing for the lowest common denominator of professional content: motivational quotes, humblebrags reframed as "lessons," recruiter spam, and corporate PR dressed up as personal reflection. None of it is written for a developer, a designer, or a founder specifically. It's written to perform generically well across a hundred unrelated industries at once.

Forg doesn't have that problem, because it doesn't try to serve everyone. It's built for one type of person: someone building something, whether that's a startup, a side project, a piece of open-source software, or a portfolio of shipped work. That narrower focus does two things at once.

It keeps out the noise that has nothing to do with your work — no "excited to announce" hiring posts, no engagement-bait about leadership lessons, no AI-polished corporate updates from people who have never shipped anything themselves. And it means the people you're actually connecting with are self-selected for the same thing you are: building, shipping, and grinding, not managing a personal brand.

That's the second, quieter reason forg avoids the AI slop problem LinkedIn has. It's not just that shorter-form, work-anchored posts are harder to fake convincingly. It's that the audience itself has no appetite for it. A community of people who can tell the difference between a real commit history and a vague "thrilled to share" post doesn't reward generic AI copy the way a general-audience feed does.

Résumé-Shaped Profiles Don't Fit Builder-Shaped Careers

LinkedIn's schema assumes your professional story is Company A, then Company B, then Company C. Titles. Dates. A neat vertical stack of employment.

That schema breaks the moment your career doesn't look like that:

• A developer with five shipped side projects and one job

• A student with three products and real users, but no formal work history

• An indie hacker running a profitable SaaS with no employees to list

• An open-source maintainer whose real body of work lives in commit history, not a job title

• A designer whose best work is a Figma file and a launch thread, not a bullet point

None of that has a native home on LinkedIn. You end up copy-pasting links into an "About" section that was never designed to hold them, hoping someone actually clicks through instead of skimming your job titles and moving on.

A forg.to profile is built the other way around. Your identity is your build history: what you shipped, when you shipped it, and what happened next. It's a changelog, not a résumé.

What forg.to Actually Gives You

Skip the pitch and look at the mechanics. This is what's live on the platform today:

A verified builder profile. A dedicated home at forg.to/@you for your product, your stack, your links, and your entire build history — with shipping streaks and an immutable changelog attached to it. It's proof of work, not a claim of work. Anyone can list "React" as a skill on a résumé. Not everyone can point to a running streak of shipped updates.

Your actual work, rendered live, not pasted as links. GitHub contribution graphs, LeetCode and Codeforces problems solved, YouTube tech videos, Medium and dev.to articles — all of it shows up on your forg profile as interactive, embedded widgets instead of a wall of URLs nobody clicks. On LinkedIn, this same information gets flattened into a plain text line in your "About" section, if it fits at all. On forg, it's the profile.

A weekly launch, not a one-time launch. Every Monday, new products go live on the forg Launchpad in front of an audience of people who actually build things — not bots, not tire-kickers. Most launch platforms give a product one loud day and then let it disappear. Forg treats launch day as chapter one, not the whole book.

Write once, reach three platforms. Post an update on forg and cross-post it to X, LinkedIn, and Bluesky in a single click — instantly or scheduled. Notice what that means: forg isn't asking anyone to quit LinkedIn cold turkey. It's making LinkedIn one distribution channel among several, instead of the only place your professional voice lives.

A changelog that lives on your own domain. Connect your forg timeline via RSS to your own website's changelog page. Your updates stay on infrastructure you actually own, not rented space inside someone else's algorithm.

A feed built around momentum, not moments. Every update, feature, and milestone gets its own post on your timeline, so your audience follows the whole story of a product, not just its launch day. Attention compounds the more you actually ship — which is a very different incentive than a feed that rewards whoever wrote the most emotionally engineered caption that week.

Today, that's over 10,000 builders and counting, documenting real products instead of performing a career.

LinkedIn vs. Forg, Side by Side

LinkedIn Forg Identity built around Job titles and employment dates Shipped products and updates Design era Early-2010s corporate template Modern, dark-first, product-led Audience Every industry and job function Developers, designers, founders, indie hackers Feed composition Recruiter posts, HR announcements, corporate PR, motivational content Product updates, launches, and build logs Content quality signal Engagement and reach Verified shipping history AI content saturation ~40%+ of long-form posts fully AI-written (Pangram, 2026) Content is tied to real, dated, shippable work Profile depth Self-reported skills, no verification Immutable changelog, streaks, proof of work Skill proof A typed line under "Skills," unverified Live GitHub, LeetCode/Codeforces, YouTube, and article widgets What gets rewarded Polished storytelling about work The work itself

A Note on What LinkedIn Still Gets Right

To be fair: LinkedIn is still useful for passive job discovery, staying loosely tied to former colleagues, and showing up in recruiter searches. Those aren't nothing, and most builders should keep a presence there for exactly those reasons.

That's also why forg.to doesn't ask anyone to delete their LinkedIn. It lets you cross-post your updates there in one click, so LinkedIn becomes a distribution channel instead of the place where your professional identity is forced to live. Keep the directory listing. Just stop mistaking it for your professional home.

FAQ

What is the best LinkedIn alternative for developers and builders in 2026? For people whose career is defined by what they ship rather than where they've been employed, forg.to is built specifically for that: a profile structured around products, updates, and proof of work instead of job titles.

Is forg.to trying to replace LinkedIn entirely? No. Forg positions itself as your professional home, while LinkedIn stays useful as one of several distribution channels — you can cross-post updates from forg directly to LinkedIn, X, and Bluesky in one click.

How is forg.to different from a portfolio site? A portfolio site is usually built once and forgotten. Forg is a living timeline — every update, milestone, and launch adds to your build history automatically, and your audience grows with the story instead of only seeing a static snapshot.

Why does design matter for a professional network? Because a professional network is where people form a first impression of your work in seconds. A dated, cluttered interface undersells serious work; a considered one lets the work speak for itself. It's the same reason a well-designed portfolio outperforms a cluttered one — the container shapes how the content is read.

Does forg.to have the same recruiter spam and corporate content as LinkedIn? No. Forg is built specifically for people building something — a startup, a side project, open-source software — rather than every profession on earth. That narrower audience means the feed stays focused on shipped work instead of hiring announcements, motivational posts, and generic corporate content.

Can I show my GitHub, LeetCode, or content on my forg.to profile? Yes. Forg renders your GitHub contribution graph, LeetCode and Codeforces solve counts, YouTube videos, and Medium or dev.to articles as interactive widgets directly on your profile, instead of as plain links buried in an about section.

Who is forg.to for? Developers, designers, indie hackers, founders, and anyone whose most impressive work lives in shipped products rather than a job history — including people with no formal employment history at all.

Read the full article on Forg →

Picture this.

You write a brilliant article. It ranks number one on Google. You check your traffic and it is falling anyway.

No penalty. No ranking drop. Just fewer clicks.

Welcome to marketing in 2026.

The Search Landscape Just Flipped

For twenty years, the deal was simple.

Write good content, rank high, get clicks. Traffic meant visibility and visibility meant growth.

That deal has quietly been cancelled.

AI Overviews, AI Mode, ChatGPT Search, Perplexity, Claude. These are not just new tools. They are a structural shift in how people find information. And they are eating traffic that used to flow to your website.

The numbers are hard to look at if you live on organic traffic.

Zero-click searches hit between 58.5% and 68% of all Google searches in 2026. AI Overviews now appear on 48% of search results pages, up 58% year over year. One study from Seer Interactive across 25 million impressions found organic click-through rates have fallen 61% when an AI Overview is present.

The kicker: according to Semrush data, 93% of searches conducted in Google's AI Mode end without a single click to any external website.

Ninety-three percent.

What Actually Happened

Here is the short version of why this happened.

Google introduced AI Overviews in 2024 and AI Mode in 2025. Both formats answer questions directly inside the search results page. The user asks something, gets a synthesised answer, and often never needs to visit a website.

OpenAI launched ChatGPT Search. Perplexity built a full search engine. Microsoft integrated AI into Bing. The result is that people now ask questions to AI systems in natural language rather than typing keywords into Google.

Nearly two-thirds of buyers now start their research using generative AI rather than traditional search.

AI crawlers, including GPTBot, ClaudeBot, and Perplexity Bot, now represent approximately one-third of all organic search activity. These bots do not render JavaScript. They need clean, fast, well-structured content. They have no patience for slow-loading pages or confusing site architecture.

The buyer journey has changed. And most marketing strategies have not caught up.

The Traffic Loss Is Real. So Is the Opportunity.

Before the panic sets in, a few things worth knowing.

First, transactional queries are the least affected. Only around 10% of commercial queries trigger an AI Overview. If someone is searching to buy something, Google still largely shows traditional results. AI search is mostly eating informational traffic, not purchase-intent traffic.

Second, the traffic that AI does send is higher quality. ChatGPT-referred visitors spend an average of 15 minutes on a website versus Google-referred visitors at 8 minutes. Sessions from AI referrals grew 527% year over year in the first five months of 2025.

Third, only 16% of brands are systematically tracking their performance in AI search. That means 84% of your competitors are flying blind. The brands that get serious about this now are locking in positions that will be extremely hard to recover later.

The loss is real. The opportunity for those who adapt is also real.

SEO Is Not Dead. It Mutated.

The phrase "SEO is dead" shows up every two years. It has been wrong every time.

What has changed is the destination of good SEO practice.

Traditional SEO optimised for ranking. Page position one, page position two. Blue links. Click-through rates.

A new discipline called Generative Engine Optimization (GEO) optimises for citation. Not where do you rank in a list of ten links, but do AI systems mention you, quote you, or pull from you when answering questions your customers are asking.

These are different goals and require somewhat different strategies.

The good news: GEO is built on the same foundation SEO always rewarded. High-quality content. Expertise and authority. Trustworthiness. Real sources, real data, real expertise. Google calls this E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) and AI systems are using similar signals to decide whose content to surface.

A Princeton, Georgia Tech, and IIT Delhi joint study found that adding specific statistics, citing credible sources within your content, and using quotes from named experts increased AI citation rates by 30 to 40 percent across tested queries.

Specific beats vague. Every time.

The Zero-Click Is Not Zero Value

Here is the mindset shift most marketers need to make.

Zero-click does not mean zero value.

When your brand appears in an AI Overview or a ChatGPT answer, the user saw you. They did not click. But your brand name was mentioned in the answer to a question they were asking. That is visibility. That is trust signaling. That is brand recall that shows up as direct or branded search traffic days or weeks later.

Similarweb research found that users who encounter a brand in an AI Overview often search that brand name directly later. The branded search spike after zero-click appearances is measurable, it just gets missed by attribution models that only count last-click.

The metric for AI search is not just clicks. It is citation share. Share of voice inside AI-generated answers. Brand mention frequency across ChatGPT, Perplexity, and Google AI Overviews.

If you are not measuring that, you are measuring the old game.

Backlinks Still Matter. Just Differently.

The relationship between backlinks and authority has not disappeared. It has been reframed.

In traditional SEO, a dofollow backlink passed PageRank. Quantity plus quality determined domain authority and domain authority influenced ranking.

In the AI search era, backlinks now serve as semantic bridges.

A link from a relevant, authoritative publication tells AI systems: this site is part of the same topic cluster as this authority source. It is less about voting power and more about topical validation. AI models use backlinks as one proxy for trust, then make their own judgment about whether your content is worth citing based on its depth, specificity, and credibility.

What this means practically: a single dofollow backlink from a genuinely relevant, high-quality source is worth more than fifty links from unrelated directories. Context and relevance now outweigh volume.

This is also why getting your product listed and mentioned across the right platforms matters more than it used to. When a builder launches on forg.to, for example, they receive a free dofollow backlink from a domain in the exact context where their product belongs, a professional network of developers and builders. That kind of contextually relevant link, placed in a community that actually uses tools like yours, does more work than a generic directory listing. It is the right source, in the right context, pointing at the right content.

Unlinked brand mentions also carry more weight than they used to. An AI model reads text, not just link structure. A mention in a respected publication without a hyperlink still contributes to how AI systems understand your brand's authority and relevance.

What Actually Works Now: A Practical Framework

Answer real questions with real depth.

AI systems prefer sources that answer questions comprehensively. Not keyword-stuffed articles. Not thin content padded to a word count. Actual, thorough, useful answers written by people who know what they are talking about.

Write like someone asked you a question in person and you gave them your full, honest, expert answer.

Use structured data and semantic HTML.

JSON-LD structured data, clean heading hierarchies, proper use of lists and tables. AI crawlers parse these signals to categorise and interpret your content. Schema markup is no longer just an SEO nicety. It is how AI systems understand what your content is about.

Get cited in the right places.

Third-party mentions, expert quotes in publications, citations in reports and comparisons. AI models recognize patterns: who discusses a brand, in which contexts, and how frequently. Appearing in the right conversations across trusted sources builds the entity authority that influences citation.

Write for humans using natural language.

People ask AI systems full conversational questions. "What is the best project management tool for a small engineering team?" not "project management tool small team." Your content needs to match that natural language. FAQ sections, question-based headers, specific use-case coverage.

Prioritise E-E-A-T signals.

Author bios that demonstrate actual expertise. First-party research and original data. Expert quotes from named, credible sources. These are the signals both Google and AI systems use to evaluate whether your content deserves to be cited.

Track the new metrics.

Run manual prompts in ChatGPT, Perplexity, and Google AI Overviews. See if and how your brand appears. Monitor branded query impressions in Google Search Console. Watch for unexplained branded search spikes after content publication, that is your zero-click attribution signal. Tools like Profound and Otterly.AI now track LLM mention frequency at scale.

The Ads Are Coming for AI Search Too

Worth mentioning because it changes the competitive landscape.

Google confirmed in 2025 that AI Overviews now include Search and Shopping ads on desktop. AI Mode also shows ads. An educational query about dogs on long flights might now surface a sponsored carrier bag inside the AI answer.

This is Google monetising the zero-click environment it created. Brands that relied purely on organic traffic are now competing for visibility against paid placements inside AI summaries.

It is not a new development conceptually. It is just arriving in a new format.

The practical response is the same as it has always been: build enough organic authority and brand trust that you appear in AI answers regardless of paid competition, while using paid placement strategically for high-intent queries.

Where This Is All Heading

AI search visits grew 42.8% year over year, rising from 15.6 billion in Q1 2025 to 27.4 billion in Q1 2026. The ratio of traditional Google users to AI search users fell from 4.9 to 1 down to 3.5 to 1 in a single year.

The direction is not ambiguous.

Search is not dying. It is fracturing. People are searching more than ever, across more tools than ever: Google, ChatGPT, Perplexity, Claude, Gemini, and whatever comes next.

The marketers who are winning are the ones who stopped asking "how do I rank in Google?" and started asking "how do I become the source AI systems trust?"

Those are related questions but they are not the same question.

The answer to the first is keywords, backlinks, and technical SEO.

The answer to the second is authority, specificity, depth, trust signals, and getting mentioned in the right places by the right sources consistently over time.

That has always been what good marketing actually was.

AI search just made it impossible to fake.

Read the full article on Forg →

Open LinkedIn for five minutes as a developer.

You will see a founder crying about failure in an airport lounge. A recruiter posting "Excited to share that I'm hiring!" for the fourteenth time this week. A motivational quote about hustle printed over a sunset. Three humblebrags disguised as life lessons. One "I'm grateful and blessed" announcement with 4,000 likes.

And somewhere, buried under all of it, maybe one actually useful post.

This is the daily reality of LinkedIn for most programmers. They tolerate it because they feel they have to. They hate it because, honestly, it deserves to be hated.

Here is exactly why.

The Spam Never Stops

The moment you put "developer" in your headline, the messages start.

About 35% of LinkedIn connection requests are followed by aggressive sales messages, according to research from email management company Superhuman. That means one in three people trying to "connect" with you are actually trying to sell you something.

Recruitment spam is worse. You will receive messages for roles you are wildly unqualified for, roles that require seven years of experience in a three-year-old framework, roles where the salary range is "competitive" (which means they will not tell you), and roles that list seventeen required skills for what is clearly a junior position.

Job offers are often missing critical information, with many listings omitting salary ranges or listing an overwhelming number of requirements without clearly explaining what the actual job entails.

Developers have noticed. Only 12% of developers use LinkedIn as their main source of technical information, according to a Stack Overflow survey. Most are on the platform purely because they feel they have no alternative, not because they find it genuinely useful.

The Fake Everything Problem

LinkedIn has a trust problem that is getting dramatically worse, not better.

In the second half of 2024, LinkedIn identified and removed 80.6 million fake accounts at the point of registration, up from 70.1 million in the prior six months. In the first half of 2025, it removed roughly 83.4 million.

Let that sink in. Over 200 million fake accounts removed in a single year. And those are only the ones they caught.

Criminals are now using deepfake technology, AI-generated job descriptions, and automated recruiter bots to convincingly impersonate real companies, real recruiters, and even real HR executives, tricking developers into fake interviews and handing over personal data.

Gartner expects one in four candidate profiles globally to be fake by 2028.

When a quarter of the profiles on a professional network might not be real people, the word "professional" starts to lose its meaning.

The fake content problem runs deeper than just bots. LinkedIn has forced its users to project a facade where a perfect professional is the only persona who succeeds. The result is a platform full of people performing success rather than actually sharing it. Every failure becomes a lesson. Every setback becomes a growth story. Every ordinary Monday becomes an opportunity for a grateful reflection.

There is no measure to check if something is real or not. A developer could add "Frontend Architecture at Google" to their profile and it shows up without any verification.

The Algorithm Is Working Against Developers Specifically

Here is a problem that gets almost no attention but affects every developer on the platform.

LinkedIn's algorithm penalizes external links.

That means every time a developer does what comes naturally, sharing a GitHub repo, linking to a dev.to article, posting about a product they shipped, sharing a YouTube video of a technical talk, the algorithm actively reduces how many people see that post.

Posts are getting shorter, with 800-1,000 characters being the sweet spot, and links still hurt your post.

Think about what this means for developers. The most useful things a developer can share, working code, technical writeups, live products, real contributions, are exactly the things the platform discourages. Meanwhile, vague motivational posts with no external links thrive.

Sponsored content and ads now fill almost 40% of the LinkedIn feed. The organic space left for actual human content is shrinking every quarter.

Reach has dropped approximately 50% year-over-year for most creators according to researcher Richard Van Der Blom's data. Developers who were getting reasonable traction with technical posts two years ago are now getting a fraction of the views for the same quality content.

LinkedIn tracks what they internally call "viewer tolerance," reducing visibility for authors whose posts are consistently ignored. So if your technical posts land with a small but engaged audience, and get scrolled past by the majority of your connections who followed you for other reasons, the algorithm punishes you further.

It is a trap. The more developer-focused your content, the less LinkedIn wants to show it.

The Profile Format Was Built for Someone Else

Now set aside the feed entirely and look at the profile itself.

LinkedIn's profile structure makes complete sense if your career is: company A, then company B, then company C. Employment history. Job titles. Credentials. Start dates and end dates.

It makes very little sense if you are:

• A developer with ten shipped side projects and one job

• A student who has built three products with real users but no formal work experience

• An indie hacker running a profitable SaaS without employees

• An open source maintainer whose most important work exists in repos, not on payroll

• A developer whose most impressive skills are visible on LeetCode, Codeforces, GitHub, and YouTube, not in a bullet point list

There is no native space for your competitive programming ranking. No place for your LeetCode solve count. No way to surface your dev.to articles or Medium posts as actual content rather than buried links. No integration with your YouTube channel showing your technical talks. No live GitHub contribution graph. No product showcase with real metrics.

To put any of this on LinkedIn, you manually copy-paste links into sections that were not designed for them, hope a recruiter notices, and accept that it looks like an afterthought. Because it is.

LinkedIn was designed for a professional world that runs on employment. It was not designed for builders.

Your Work Is Scattered and That Is a Professional Problem

Here is the thing no one talks about.

Developers today have their professional identity spread across a dozen platforms.

Code lives on GitHub. Competitive programming rankings live on Codeforces and LeetCode. Technical writing lives on dev.to or Medium. Tutorial content lives on YouTube. Product launches live on Product Hunt. Side project metrics live in a Notion doc nobody else can see. Open source contributions are visible on individual repo pages but not aggregated anywhere meaningful.

Ask most developers to send you a link that shows everything they have done professionally and they cannot. They send you their GitHub and hope you click around long enough to figure out the rest. Or they spend a weekend building a personal portfolio site, which they update once and forget.

This fragmentation is not just inconvenient. It actively hurts developers professionally.

A recruiter evaluating you has sixty seconds. If your professional presence requires them to visit four platforms, read three readmes, interpret a contribution graph, and check a YouTube channel, most of them will not bother.

This is the gap forg.to was built to close.

Instead of hunting across platforms, your forg.to profile aggregates everything into one place. Your GitHub activity, your competitive programming profiles from Codeforces and LeetCode, your content from YouTube, dev.to, and Medium, your products, your milestones, your metrics. All visible in one profile, fully customizable, structured the way a builder actually works rather than the way an HR database expects.

A developer profile that surfaces your actual professional identity, not just where you have been employed.

The Cringe Content Problem

Every developer knows this feeling.

You open LinkedIn hoping to find a job, make a connection, or learn something useful. Instead, you scroll through:

A founder revealing the three lessons they learned from almost going bankrupt, written as a dramatic twelve-paragraph essay. A developer announcing they just got their first offer after 847 days of rejection, with crying emojis. A tech lead explaining why "soft skills are actually more important than hard skills" in what is clearly a post optimized for engagement, not truth. An AI-generated post disguised as a personal story, using phrases no human being would naturally say.

Developers are building open source tools, solving problems late at night with no company name behind them, but they find the platform's fake professionalism intolerable.

The content culture on LinkedIn actively rewards performance over substance. Emotional posts that make people feel something outscore technical posts that actually teach people something. This is fine for the platform's engagement metrics. It is useless for a developer trying to find their people or get found by the right opportunities.

The Verification Gap

One of the most specific frustrations developers have with LinkedIn is that nothing is verified.

Anyone can claim any skill. Anyone can claim any job title. Anyone can list any company as their employer. Anyone can list themselves as a React expert, a cloud architect, a machine learning engineer, regardless of whether they have ever written a single line of relevant code.

Endorsements are a joke. Thousands of people have endorsements for skills from connections who have never seen them work. The endorsement system measures social reciprocity, not competence.

For developers specifically, this is maddening. The whole point of working in a field where you can show your code is that the work is verifiable. The GitHub contribution graph is real. The merged pull request is real. The live product is real. The LeetCode rating is earned through actual problem-solving.

None of that verifiability transfers to LinkedIn. It all gets flattened into the same unverified list of self-reported skills.

What Developers Actually Need

The complaints about LinkedIn are legitimate and consistently made. What is less often articulated is what developers actually want instead.

The answer, reading across every developer community that has discussed this, is roughly the same:

A professional home where the work speaks. Where GitHub activity is a first-class signal, not a buried link. Where shipped products are visible alongside the person who built them. Where competitive programming rankings, writing, technical content, and open source contributions all live together in one coherent identity. Where the profile shows what you can do, not just who has employed you.

Where verification comes from the work itself rather than from unchecked self-reporting.

That is a fundamentally different kind of professional profile than LinkedIn offers. And it is what builders increasingly need as the proof-of-work era of hiring takes hold.

Platforms like forg.to exist because LinkedIn was not built for this. Your profile on forg.to connects your GitHub, your Codeforces and LeetCode rankings, your dev.to and Medium articles, your YouTube channel, your products and startups with real metrics, all of it aggregated into a single professional identity that you control and customize. Not a social feed optimized for engagement. A professional record optimized for truth.

The question is not whether LinkedIn is useful. It still is, for some things.

The question is whether it is the right home for your professional identity as a builder.

For most developers, increasingly, the honest answer is no.

A Note on What LinkedIn Gets Right

To be fair: LinkedIn is useful for passive job discovery, for staying loosely connected to former colleagues, and for appearing in recruiter searches.

These are not nothing. Most developers should maintain some presence on LinkedIn for these reasons alone.

But maintaining a minimal presence for discoverability is different from treating LinkedIn as your actual professional home. The platform was not built for builders, does not surface builder-relevant proof of work, penalizes the links and content that matter most to developers, and is increasingly overrun with fake accounts and AI-generated noise.

Use it as a directory listing. Not as the place where your professional identity actually lives.

That place should be somewhere built for people who build things.

Read the full article on Forg →

When you start learning something and want to get good at it, the first thing that comes to mind is finding the best tutorial. This is especially common in tech.

Tutorials feel productive. You follow along, your code works, and by the end of the video you have built something. That feeling of progress can be rewarding, which is why many people spend hours jumping from one tutorial to another.

The problem is not tutorials themselves. The problem is staying in tutorial mode forever.

The Tutorial Trap

When you follow a tutorial step by step, you are often following someone else's thinking rather than developing your own. You know where to click because the instructor told you. You know what code to write because it is already on the screen.

Think about a student who copies answers during a test. Even if they copy every answer correctly, it doesn't mean they understand the material afterward. In the same way, completing a tutorial doesn't automatically mean you can build the same thing on your own.

This is where building projects becomes powerful.

What Separates Builders from Consumers

When you build something yourself, there is no instructor telling you what to do next. You have to remember concepts, search for solutions, make mistakes, and figure things out. That process forces your brain to actively recall information instead of passively consuming it.

Learning by building is one of the most effective ways to learn because it turns knowledge into experience. Instead of remembering what someone else did, you begin to understand why it works and how to apply it in different situations.

But there is one challenge with learning by building: figuring out what to build.

Many people solve this problem by building clones of existing products. There is nothing wrong with that. Cloning a website or app can teach you how real products are structured and how different technologies work together.

When Cloning Becomes a Trap

The problem starts when cloning becomes the only thing you do.

A clone teaches implementation, but it doesn't teach product thinking. It doesn't force you to ask questions like:

• Who is this for?

• What problem am I solving?

• Why would someone use this instead of something else?

Those are the questions that separate developers from builders.

Instead of copying products exactly, I think beginners should use them as inspiration.

A Personal Example

For example, I built a web app called CanvArt.

At first glance, the interface looks similar to Pinterest. But the purpose is completely different.

Pinterest is mainly a place for collecting and saving inspiration. CanvArt, on the other hand, is a platform where artists can showcase their work. Whether someone is a professional artist or a complete beginner sharing their first sketch, they can post their creations and receive visibility.

You can check it out on forg: https://forg.to/products/canvart

The design inspiration came from an existing product, but the idea itself was original.

That process taught me much more than building another Pinterest clone ever could. It forced me to think about users, features, and the overall purpose of the platform.

Final Thoughts

Project thinking comes from creating, not copying.

The goal is not to avoid inspiration. The goal is to use it as a starting point, then build something that reflects your own ideas, solves your own problems, and teaches you lessons no tutorial ever could.

Tutorials can teach you the tools. Clones can teach you implementation.

But building something original is what teaches you how to think.

Read the full article on Forg →

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.

For Teams: The Multiplier Effect

The savings scale surprisingly well. A single developer can typically save around $150-200 per month ($1,800-2,400 per year). A team of five saves roughly $750-1,000 every month, while a 20-person engineering team can eliminate around $36K-48K in token waste every year.

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 Use Cursor Instead?

Same thing works:

copium wrap cursor

Or Aider:

copium wrap aider

Or any OpenAI-compatible tool:

export OPENAI_API_BASE=http://localhost:8787/v1

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

The Tool I Use

Copium (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: github.com/iKislay/copium

Read the full article on Forg →

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.

Read the full article on Forg →

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 SizeItems KeptToken SavingsRetrieval Rate100 items12-1882-88%2.1%500 items15-2595-97%2.8%1000 items18-3097-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:

1. You are paying tokens to save tokens (negative ROI for small arrays)

2. Summarization adds latency (2-5 seconds vs 15ms)

3. The summary is lossy and irreversible. If the LLM needs the original, it is gone

4. 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

1. 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.

2. Reversibility is non-negotiable. The moment you permanently delete context, you introduce failure modes. CCR makes compression a zero-risk operation.

3. The Kneedle algorithm is underrated. Finding optimal K without a training set is hard. Kneedle solves it elegantly for sorted score distributions.

4. 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

Read the full article on Forg →

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 aand 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.

Read the full article on Forg →

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.

Read the full article on Forg →

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.

LinkedIn

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.

Read the full article on Forg →

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.

Read the full article on Forg →

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

Welcome to Forg.

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?

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.

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:

1. Finish your profile and link your accounts

2. Add your product to Forg

3. Post something genuine: a thing you learned, a problem you're wrestling with, an opinion you can defend

4. Engage with posts from other builders you actually find interesting

5. 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.

Read the full article on Forg →

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.

Read the full article on Forg →

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.

Read the full article on Forg →

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.

Read the full article on Forg →

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.

Read the full article on Forg →

Professional networking has not died. It has just splintered. The days of LinkedIn being the only answer are over, and in 2026, where you build your professional presence depends entirely on who you are and what you actually do.

This is a breakdown of the platforms worth your time, what each one is genuinely good at, and who should be on which one.

LinkedIn

LinkedIn remains the largest professional network in the world, with over a billion registered users. If you work in corporate environments, B2B sales, traditional industries, or executive circles, it is still the first place people look you up.

Recruiters live on LinkedIn. Enterprise hiring still runs through it. Company announcements, industry news, and professional milestones all live here in a way that other platforms have not replicated at scale.

The honest criticism: the content feed has become difficult to use. AI-written posts, engagement bait, and performative storytelling have made it harder to find signal. For developers and builders specifically, the "skills" endorsement system does not reflect technical credibility well. LinkedIn was built around employment history as the anchor of professional identity, and that model creates friction for anyone whose best work does not fit neatly into a job title.

Still, the network effects are real. You cannot ignore it entirely.

Best for: Corporate roles, executive networking, B2B sales, traditional industries, job searching at scale.

GitHub

GitHub is technically a code hosting platform. In practice, for developers, it functions as a professional network.

Your commit history, open source contributions, and public repos tell a more credible story than any job title can. Hiring managers at technical companies look at GitHub profiles. Open source contributors build reputations that travel across company lines. Projects with real stars and activity carry weight in a way that a LinkedIn skill endorsement simply does not.

The limitation is that GitHub is passive. There is no mechanism to broadcast what you are working on, no feed for professional identity, and no way to tell a coherent narrative about your career arc. The signal is there. Surfacing it requires work on your end.

Best for: Developers, open source contributors, anyone building a technical portfolio.

Wellfound

Wellfound, formerly AngelList Talent, is the professional network for the startup ecosystem. It sits at the overlap of networking and hiring in a way that is specific to early-stage companies.

Founders and companies on Wellfound typically list salary ranges, equity, funding stage, and company size upfront. The transparency is unusual compared to traditional job platforms. The community includes investors, operators, founders, and people actively working in or building startups.

It is narrower than LinkedIn by design. For that target audience, that narrowness is the point.

Best for: Startup job seekers, founders, early-stage operators, angels and investors.

forg.to

Most professional networks are built around where you have worked. forg.to is built around what you are actively building.

It is a professional network for developers and builders where the primary signal is current activity, not employment history. Profiles aggregate work from across the web: GitHub, LeetCode, dev.to, Medium, YouTube, Dribbble, and more. The result is a live picture of what someone is actually working on right now, not just a list of past employers.

There is also a Launchpad feature for indie product launches, which gives builders a dedicated layer of visibility for the things they ship outside of their day job.

The core insight forg.to operates on is that for a lot of developers and indie builders in 2026, professional identity is not about where you work. It is about what you are creating. A GitHub profile shows commits. A LinkedIn profile shows jobs. forg.to tries to show the full picture of a builder's ongoing output.

Worth getting on early while the community is still growing.

Best for: Developers, indie hackers, technical founders, and anyone whose professional identity is defined by what they build, not where they are employed.

Contra

Contra is built specifically for independent professionals. The platform is commission-free, meaning you find projects, close clients, and keep everything you earn without platform fees.

Beyond the financial model, Contra has grown into a genuine community for freelancers and consultants. You can build a public profile that showcases past work, set your rates, and attract inbound interest from clients. For developers and designers who work independently or run a solo consulting practice, it is a far more purpose-built environment than trying to adapt LinkedIn for freelance positioning.

Best for: Freelancers, independent consultants, contract developers and designers.

X (Twitter)

X is not a professional network in the traditional sense. But for developers, founders, and builders, it functions as one of the highest-leverage places to build a public presence.

The developer and startup community on X is dense and active. Real-time conversations happen around launches, technical topics, industry news, and startup milestones. Building in public on X, posting about what you are shipping, sharing technical learnings, or just being consistently present in your niche generates the kind of organic professional visibility that no structured network can replicate.

The algorithm rewards consistency and engagement, which means the bar to getting seen is real. But for anyone willing to show up regularly, the compounding effect on professional reputation is significant.

Best for: Founders, developers building in public, technical content creators, anyone doing personal brand work in the startup or dev space.

Polywork

Polywork was built on the premise that professionals are more than a single job title. A developer who also consults, writes, teaches, and ships side projects has no clean home on LinkedIn. Polywork was designed to represent that kind of layered, multi-track professional identity.

Adoption has grown slowly, but the product has matured. It works best for people who genuinely maintain multiple parallel tracks of work and want a single place that holds all of it.

Best for: Multi-hyphenate professionals, creators with technical backgrounds, people running parallel careers.

How to Choose the Right Platform in 2026

There is no single right answer because professional identity is not one-size-fits-all in 2026. The better question is: where is your actual work visible?

For developers and builders, a practical stack looks like this: GitHub for technical credibility, forg.to or X for builder identity and active presence, LinkedIn because the hiring world has not fully moved on, and Wellfound or Contra depending on whether you are looking for a startup role or operating independently.

The platforms gaining real traction are the ones where your profile reflects what you are doing right now, not what you did at a company three years ago. Active work is harder to fake and more useful to the people evaluating you.

Pick the platforms that show the version of you that is actually worth showing.

Frequently Asked Questions

What is the best professional networking platform for developers in 2026? GitHub remains essential for technical credibility, but developers who want to show a broader picture of their work use platforms like forg.to, which aggregates active building activity across GitHub, dev.to, YouTube, and more. LinkedIn is still relevant for traditional hiring but has limits for the developer identity.

Is LinkedIn still worth using in 2026? Yes, but selectively. LinkedIn is still the dominant platform for corporate hiring, B2B networking, and traditional industries. For developers and independent builders, it is necessary to maintain but not sufficient on its own.

What platforms are best for indie developers and builders? forg.to is specifically designed for builders whose professional identity is defined by what they are creating rather than where they are employed. X is also strong for anyone building in public. GitHub is the baseline for technical work.

What is the best professional network for freelancers? Contra is purpose-built for independent professionals and is commission-free. LinkedIn still drives inbound for many freelancers, but Contra gives a cleaner setup for showcasing independent work and finding clients.

Which professional network is best for startup founders? Wellfound (formerly AngelList) for ecosystem-specific networking, X for real-time community presence and building in public, and LinkedIn for traditional investor and enterprise connections.

Read the full article on Forg →

There's a version of professional networking that made sense in 1995.

You got a job. You stayed for a few years. You updated LinkedIn. You moved to the next job. Your value as a professional was something a company decided for you.

That version of a career is effectively dead. But the profiles we use to represent ourselves haven't caught up.

The Resume Question Problem

LinkedIn was built around a specific set of questions:

• Where do you work?

• Where did you study?

• What companies have employed you?

These are the right questions if your identity as a professional is defined by who's willing to put you on payroll.

They're completely wrong questions if you're a 22-year-old who's shipped three products, maintains an open source library with 2k stars, runs a SaaS generating $1,500/month, and has never had a "real" job.

The best developers, designers, and founders building today have careers that a traditional profile physically cannot represent. Not because they're not accomplished — because the format is wrong.

What forg.to Is

forg.to is a professional network for developers, builders, and people in tech — built around what you're building, not just where you've worked.

This is a precise distinction and it's worth being precise about.

forg.to is not a build-in-public platform. It's not a product launch board. It's not a developer-only social media feed. It is a professional network — with the same professional gravity that LinkedIn carries for corporate hiring — built for the generation of professionals whose credibility lives in what they've shipped.

A forg.to profile includes:

• Products and startups you've built

• Project updates, milestones, and progress over time

• Development activity

• Portfolio work

• Verified business metrics — revenue, users, traction

• Community engagement and contributions

The profile is a living record of work. It updates as you build, not just as you switch employers.

Who It's Actually For

forg.to is built for a specific type of professional:

Developers who ship things on weekends. Indie hackers running profitable side projects. Student founders. Designers who publish daily. Open source contributors. Prolific builders whose best work is invisible on a traditional resume.

Not for people whose career arc is "individual contributor → manager → senior manager → director."

For people whose career arc is "idea → built it → shipped it → built something else."

If the most interesting thing you've done professionally has never appeared on your LinkedIn, forg.to is where it belongs.

Why This Isn't Just Another Developer Platform

The easy confusion is positioning forg.to as a niche tool — a place for a specific type of person doing a specific type of thing.

That's wrong.

The claim is bigger: that activity-based professional identity is the future of professional networking, full stop. Not just for developers. For every category of professional where what you produce matters more than who employs you.

Developers are the first demographic where this is obviously true. But designers, researchers, founders, creators, and independent professionals of all kinds are building careers that don't fit the resume model anymore.

forg.to is building the professional infrastructure for that shift.

The Actual Future of Professional Profiles

The next generation of professionals will not be known primarily by their job titles.

They'll be known by what they've built, what they've contributed, what they've shipped, and what their work has actually produced.

The professional profile of 2030 is a living record — documented progress, real metrics, actual work — not a formatted list of companies that were willing to pay you.

forg.to is building that infrastructure today.

Not a resume. Not a social feed. Not a portfolio tool.

A professional network built for people who've already outgrown the ones that exist.

Read the full article on Forg →

Imagine this.

You have pushed a thousand commits. Your GitHub profile is a beautiful, unbroken wall of green squares. You know you are a solid engineer.

But when a recruiter or a startup founder looks you up, what do they see?

They do not see the clever caching strategy you implemented. They do not see the hours you spent optimizing a complex database query. They just see repositories.

And honestly? Nobody has the time to clone your repo, install your dependencies, run your code, and figure out how brilliant you are. They want the story. They want the result.

This is exactly why you need a professional home on the internet. Let us get technical about why a personal website is the highest ROI project you can build.

Stop Building on Rented Land

First, stop building your reputation on rented land.

Twitter, LinkedIn, and Medium are great distribution channels. But you do not own them. If an algorithm changes overnight, your visibility drops to zero. If an API gets locked behind a paywall, your integrations break.

When you build your audience entirely on platforms you do not control, you are at their mercy. A personal website is a digital asset you actually own. It is your server, your domain, your rules.

The Ultimate Technical Playground

Second, it is the ultimate technical playground.

At your day job, you are probably locked into a specific tech stack. You are maintaining legacy React code or arguing about state management patterns. You cannot just rip out the frontend and rewrite it in SvelteKit or Astro just for fun.

But your personal site? You are the lead architect.

• Curious about Edge Functions? Deploy your site to Vercel and write a custom middleware to personalize content based on a visitor's geolocation.

• Want to learn WebGL? Build an interactive 3D landing page using Three.js that makes people drop their jaws.

• Need to understand server-side rendering? Spin up a fresh Next.js app and see how it handles hydration.

It is a low-risk sandbox. You can break things, learn deeply, and ship directly to production without waiting for a pull request approval.

SEO is Your Silent Recruiter

Third, SEO is your silent recruiter.

If someone Googles your name right now, what shows up? If you do not control the first page of Google for your name, someone else does. A custom domain gives you the power to dictate your online narrative.

This is where you write technical deep dives. Share exactly how you debugged that nasty memory leak in a Node.js microservice. Explain the architecture behind your side project, like how you used Redis for rate limiting to protect your API endpoints.

When you write about the problems you solve, you stop being just a "developer." You become an "expert."

Take a junior engineer trying to stand out. They build a simple weather application. On GitHub, it is just a README and a folder of code. But on their personal site, they write a post detailing their thought process. They explain why they chose a specific weather API, how they handled asynchronous state, and how they deployed it using GitHub Actions.

Suddenly, they are demonstrating problem-solving. They are showing how they think. This is what lands interviews. This is what attracts high-paying freelance clients.

And it scales infinitely. You write an article once. It sits on your server. It acts as a tireless, round-the-clock salesperson for your skills. Someone halfway across the world might stumble upon it and reach out with an opportunity you never even knew existed.

How to Actually Start (Without Overengineering)

So how do you actually start?

Do not fall into the classic developer trap. You know the one. You decide to build the absolute perfect custom CMS from scratch. Three months later, your site is still not live because you are endlessly tweaking a CSS grid.

Keep it simple.

• Pick a framework: Start with a modern static site generator like Astro, Hugo, or Next.js.

• Find a host: Deploy it on platforms like Vercel or Netlify.

• Claim your name: Buy a clean domain name.

• Consolidate your presence: Write a quick bio, list a few projects, and link your socials. If you want to skip the boilerplate and neatly tie your repositories, articles, and socials together in minutes, a simple developer-friendly hub like forg.to is a great way to do this without overthinking it.

Ship it.

Your professional home does not need to be a masterpiece on day one. It just needs to exist. Claim your corner of the web. Build your home. Let your code and your stories speak for themselves.

Read the full article on Forg →

If you watched this week's Google I/O 2026 keynote, you saw the shift happen live.

(Want the quick version of everything announced? Check out this short summary video of the keynote right here: https://youtu.be/wV8FVNy0yjc?si=7xAzDCXhx4LBN8W2)

The tech giant unveiled Google Antigravity 2.0. This is not just another simple coding assistant. It is a standalone platform designed to orchestrate multiple autonomous agents in parallel.

Imagine one AI agent coding your backend database. At the exact same time, another agent is writing your frontend React components. A third subagent is generating your brand assets.

All of this happens under the guidance of Gemini 3.5 Flash. This new model outperforms the previous generation on strict agentic benchmarks like Terminal Bench 2.1 and MCP Atlas. It turns multi day engineering efforts into tasks that take just a few minutes.

Then came the updates to Google Flow.

With the new Google Flow Tools, anyone can "vibe code" an app using purely natural language. You do not need to know Python. You do not need to understand JavaScript. You just tell the AI what you want to build.

You simply give in to the vibe and the software materializes.

Google pitches this as a massive win for creators. They call it the ultimate "democratization of development."

But there is a darker controversy brewing just beneath the surface of all this hype.

What does this mean for the actual tech workforce?

For decades, the software industry relied on a steady pipeline of junior developers. They were the ones assigned to write boilerplate code. They fixed minor bugs. They wrote unit tests.

This work was undeniably tedious. But it was also a vital apprenticeship.

It was how you learned to navigate a complex, messy codebase. It was how you learned what production level failure looked like. It was how you built the intuition required to become a senior engineer.

Today, those exact entry level tasks are the ones being handed over to AI.

Why would a startup pay a junior developer $80,000 a year to write basic API routes when a managed agent can do it for pennies in a matter of seconds?

The automation of the entire junior developer tier is no longer a futuristic prediction. It is happening right now.

Recent industry data shows a massive shift. Experienced developers are using AI to pump out features faster than ever before. Development teams are shrinking. Management layers are rapidly flattening.

But this efficiency creates a terrifying problem for the future of tech.

If nobody is hiring juniors today, where will the senior developers come from in 2030?

You cannot become a senior architect just by reading tutorials. You need real battle scars. You need the experience of breaking things and fixing them under extreme pressure.

By automating the bottom rung of the career ladder, companies are optimizing for short term speed while quietly destroying their long term talent pipeline.

We are entering a brand new era of "Agentic Engineering." The human developer is no longer the typist. The human is the orchestrator.

This means the role of the junior developer must radically evolve to survive.

The entry level jobs of tomorrow will not be about writing syntax. They will be about auditing AI outputs.

New developers will need to become "Forensic Coders." They will specialize in tracking down AI hallucinations. They will review agent generated logic. They will figure out exactly why an autonomous system suddenly broke a production environment.

Vibe coding is an incredible superpower for building rapid prototypes.

But when it comes to maintaining complex, enterprise grade systems, we still need absolute human accountability.

The entry level tech job is not dead. But the version of it we knew in 2023 is officially extinct.

If junior developers want to survive the era of Google Antigravity and Gemini Omni, they need to stop competing with the machine.

They need to learn how to manage it.

Read the full article on Forg →

The "Vibe Coding" Epidemic

I am graduating with a computer science degree next year. Let me tell you a secret.

(Quick note: If you prefer watching a video over reading, here is an excellent breakdown of this exact shift: https://youtu.be/KinguqY6WwU)

I have watched the entire field of software engineering mutate right in front of my eyes.

Over the last few years, the narrative shifted. We went from "learn to code and you are set for life" to "an AI agent just wrote a new operating system while I was asleep."

Right now, everyone is talking about something called "vibe coding."

If you have not heard of it, vibe coding is basically when you have zero idea how the underlying architecture works. Instead of engineering a solution, you just keep spamming prompts into Claude or GitHub Copilot until the red error squiggles finally disappear.

You do not know why the code works. You do not know why that useEffect loop finally stopped crashing your browser. You just know that the project compiled, and you are absolutely terrified to touch it ever again.

Vibe coding your way to a production codebase is the equivalent of an electrician throwing a bunch of live, uninsulated wires into your drywall, sealing it up, and praying your house does not burn down.

It might turn the lights on today. A month from now, the entire system goes up in flames.

The tech industry is waking up to this reality. The honeymoon phase of companies cramming AI into absolutely everything is officially over. We are now entering the hangover phase.

The companies that pushed AI "slop" (the generic wrappers and chatbots nobody asked for) are dying out. And the developers who rely solely on vibe coding? They are going to be the first ones on the chopping block.

So, what does this actually mean for a computer science student or a junior developer today?

It means the era of being a generalist "syntax monkey" is officially dead. But the era of the true software engineer is just beginning.

The Myth of "AI Can't Go Deep"

There is a massive amount of coping going on in the tech community right now.

You will hear developers say that AI is just a glorified autocomplete. They claim it can only write boilerplate, it cannot build complex architectures, and it certainly cannot go deep into specific engineering domains.

Here is the brutally honest truth. Basing your entire career security on the assumption that AI will always suck at something is a terrible strategy.

Maybe AI struggles to build highly complex, deeply integrated enterprise microservices today. But what about next year? What about in 2030?

AI models are evolving at a terrifying speed. If your only value to a company is that you can write a React component slightly faster than a language model, you are competing in a race to the bottom. And you are going to lose.

The generalist developer (the person who knows a little bit of Python, a little bit of JavaScript, and how to center a div) is the most at-risk role in software today. AI is simply faster, cheaper, and it does not complain about the office coffee.

To survive, you have to realize that the definition of your job has permanently changed.

Your job is no longer just typing syntax. Your job is architecture, security, domain expertise, and orchestration. You are shifting from being the person laying the bricks to being the general contractor who makes sure the building does not collapse when the wind blows.

Welcome to Validation Hell

Let me share a slightly terrifying story.

Bjarne Stroustrup, the legendary computer scientist who created the C++ programming language, recently pointed out a massive crisis happening in the industry right now.

Senior developers are literally choosing to retire early rather than deal with reviewing AI generated code.

Think about that for a second. The people with 20 years of experience would rather go fish in a lake than read one more pull request authored by an AI.

Why? Because when a human junior developer makes a mistake, it usually follows a logical human flaw. It is localized. You can trace their thought process, find the off-by-one error, and correct it.

When an AI makes a mistake, it is pure, unadulterated chaos.

It will confidently hallucinate an npm package that does not exist, opening the door for a supply chain attack. It will write code that looks perfectly beautiful on the surface but introduces three catastrophic SQL injection vulnerabilities.

It creates bloated, memory-leaking garbage that is impossible to validate. Every time you tweak the prompt, the AI rewrites the entire logic block from scratch.

As a developer in the age of AI, you are going to spend a massive chunk of your time validating, debugging, and fixing the output of machines.

Here is the catch. You cannot validate code that you do not deeply understand.

If you do not know the fundamentals, you are completely blind. You become a hostage to the AI, nodding along to whatever it spits out, completely unaware that it just leaked your entire company's database to the public internet.

The Anti-Vibe Rule (How to Actually Survive)

So how do you actually adapt to this? How do you become better than a generalist programmer who is about to be automated away?

It comes down to one golden, unbreakable rule: You should only use AI to write code that you could have written yourself.

Or, at the very absolute minimum, you should only use it to write code that you fundamentally and deeply understand line by line.

AI is the greatest productivity multiplier in the history of software. It is a phenomenal tool. But it is a tool, not a replacement for your brain.

If you use AI to bypass the struggle of learning how data structures work, how memory allocation is handled in the background, or how APIs communicate under the hood, you are building a career on a foundation of sand.

If you are a student, you still need to learn the basics. You need to know how to build a REST API from scratch. You need to understand how a missing database index can completely bottleneck a system at scale. You need to be able to look at an AI script and immediately smell that something is wrong.

The problem is that universities are still stuck in 2015. They are churning out generalists, giving you broad exposure to a bunch of theory, but very little deep, practical application.

My advice? Play the game.

Use AI to speedrun the irrelevant prerequisites and the boring busy work that your college forces you to do. Take all of that saved time and use it to go incredibly deep on a specific domain.

Become undeniably good at one thing. Maybe that is systems engineering, low latency backends in Rust, or AI orchestration itself. Build projects without using an AI crutch just to prove to yourself that you actually know how the plumbing works.

The Evolution of the Interview

Because the bar for writing code has dropped to zero, the bar for proving you are an engineer has skyrocketed.

Interviews are going to get harder. They are going to get much more practical.

People keep predicting the death of LeetCode. They assume that because ChatGPT can solve a binary tree inversion in half a second, companies will stop asking about it.

That is a massive cope.

The Data Structures and Algorithms interview was never really about the final answer. The interviewer already had the answer key. It has always been about watching how you think, how you handle pressure, and how you communicate your complex logic.

What is changing is that companies want to see you actually build. They want to pair program with you. They want to watch you architect a system live, without an AI holding your hand, to see if you actually possess baseline competency.

If your resume is entirely made up of projects that you vibe coded in a weekend, you are going to get exposed the second a senior engineer asks you to explain your own system architecture.

Practice building blind. Close the browser. Close the AI sidebar. Open a blank text file, and see if you can actually build a rate limiter or a basic WebSocket server from memory.

It is a humbling experience, but it is the absolute fastest way to find your weak spots.

Finding the Fun in the Apocalypse

I know all of this sounds dark. It sounds like the industry is collapsing and we are all doomed to be replaced by lines of Python.

But I actually have an incredibly optimistic view of where this is going.

I genuinely think the future of software engineering is about to be more fun than it has ever been.

Think about it. AI is taking over the absolute worst, most miserable parts of this job. Nobody actually enjoys writing boilerplate setup files. Nobody enjoys spending six hours debugging a missing semicolon, or reading poorly translated documentation just to figure out the syntax for a new framework.

AI is stripping away the tedious manual labor of coding. And what is left?

The fun stuff. The actual problem solving. The system design. The creative architecture.

The barrier to building something real and shipping it to actual users has never been lower. You can have an idea on a Friday night, and with the help of AI to handle the grunt work, you can have a fully functioning, deployed product by Sunday. You can move at the speed of thought.

But to do that, you need to surround yourself with the right people.

Grind culture is only miserable when you do it alone. If you find people who are genuinely curious, who actually care about building robust things instead of just chasing a tech salary, the whole process stops feeling like a grind.

This is why tapping into the right network is so crucial right now.

A great place to dive into this is a platform called Forg.to. It is a dynamic community where indie makers, developers, and tech professionals are actively coming together to build, launch, and grow their projects.

If you are looking for a place to discover groundbreaking SaaS products before they hit the mainstream, or you just want to connect with a network of passionate creators who are shaping the future of tech, Forg.to is exactly the kind of ecosystem you want to be in.

Whether you find your crew there, join a university club, or go to a hackathon and stay up for 48 hours building something ridiculous, embrace the fact that the landscape is shifting.

Look at AI not as a threat that is going to steal your job, but as an exoskeleton that allows you to build a skyscraper instead of a doghouse.

The students and developers who understand the fundamentals, who refuse to blindly vibe code, and who leverage AI as a collaborator rather than a crutch are the ones who are going to own the next decade of tech.

Back to Fundamentals

You cannot build a skyscraper if you do not understand physics. You need the fundamentals, and you absolutely cannot fake them.

There is a massive difference between watching a tutorial or letting an AI auto-complete your architecture, and actually manipulating the logic yourself. You have to force yourself to do the hard work of understanding the system, because that is the only way the concepts will permanently stick in your brain.

If you want to survive this shift in software engineering, you have to learn the "why" behind the code.

Do not just memorize patterns for an exam or rely on an LLM to bail you out of a bug. Dive deep into your language of choice, understand your data structures, and build your baseline competence from the ground up.

Stop relying on AI to think for you, and start building your own problem solving skills.

Stop vibe coding, learn your fundamentals, and start engineering.

Read the full article on Forg →

You see the headlines every week.

Microsoft, Google, and Amazon are posting record shattering profits, and everyone points to Artificial Intelligence as the golden goose.

But it is an illusion.

We are living inside a massive ecosystem of recycled money. These tech giants are using perfectly legal accounting loopholes to artificially inflate their stock prices, while the actual AI startups are burning cash like a bonfire in the dead of winter.

Before we dive into the deep end, if you prefer watching a complete detailed breakdown instead of reading, you can check out this video here: https://youtu.be/uU7CIqfJANs?si=VeG85PaWoQKS5RPZ

Now, let us talk about the corporate infinite money glitch.

It is called a "round trip revenue loop." And honestly, it is darkly hilarious.

Take a look at Microsoft and OpenAI.

OpenAI generated roughly $20 billion to $25 billion in revenue recently. That sounds fantastic until you look at the expenses. Internal financial projections for 2026 show OpenAI losing a catastrophic $14 billion this year alone. They are on track to burn through $44 billion by 2028.

So if OpenAI is bleeding out, why is Microsoft reporting explosive cloud revenue?

Because of how the investments are structured. Microsoft handed OpenAI nearly $13 billion in funding. But they did not hand over pallets of cash. They handed over Azure cloud credits.

OpenAI then turns around and uses those exact credits to buy server space from Microsoft to train its massive AI models.

Microsoft takes that usage, points it out to Wall Street, and says, "Look at all this organic cloud revenue!"

It is the corporate equivalent of giving your broke roommate $1,000 to buy your old television, and then bragging to your family that your electronics business is booming.

This is exactly why OpenAI has racked up a cloud bill exceeding $60 billion, despite bringing in a fraction of that in actual revenue. They are a furnace for recycled money.

And it gets wilder.

Google and Amazon are pulling the exact same magic trick with Anthropic.

In the first quarter of 2026, Amazon reported a staggering $30 billion in net income. Wall Street cheered. Amazon stock shot up.

But if you look under the hood, nearly $16.8 billion of that profit was not actual cash.

It was a paper gain.

Thanks to a 2016 accounting rule from the Financial Accounting Standards Board, companies can use a "mark to market" method. When Amazon originally invested $8 billion in Anthropic, they took an equity stake. Recently, Anthropic raised more money at a much higher valuation.

Because Anthropic's theoretical value went up, Amazon simply updated their own spreadsheet.

They revalued their stake in the startup, recorded the massive difference as a pre-tax gain, and funneled it straight into their net income. Not a single penny actually hit Amazon's bank account from that $16.8 billion gain.

Google did the exact same thing, booking close to $28 billion in similar non cash gains driven largely by its own stake in Anthropic.

They are padding their stats.

Meanwhile, Anthropic is struggling with the exact same gravity as OpenAI. Anthropic hit about $4.3 billion in annualized revenue, but they are sitting on $19 billion in overall costs. They are spending roughly three dollars for every single dollar they make.

The cash flow data tells the real story here.

In the exact same quarter Amazon reported that massive $30 billion profit, its free cash flow literally collapsed by 95 percent down to a mere $1.2 billion. Why? Because they spent over $44 billion on actual capital expenditures to build out the data centers these startups need.

The entire tech industry is currently relying on a handful of deeply unprofitable startups to justify a multi trillion dollar spending spree.

Big tech funds the startup. The startup buys big tech's cloud services. Big tech books the revenue, revalues the startup's equity, claims a massive profit, and their stock price goes up.

It is legal. It is brilliant.

But it is still monopoly money.

Big Tech Printing Profits While Burning Cash

This video explains the massive capital expenditures by tech giants and how their soaring profits are masking collapsing free cash flows as they build out AI infrastructure.

Read the full article on Forg →

Usually, it is just clickbait.

But after the events of May 2026, the joke is finally over.

We are no longer talking about a minor algorithm tweak or a penalty for buying spammy backlinks.

Google has fundamentally altered the architecture of the internet.

If you want to catch up on the sheer volume of product drops from Google I/O 2026, you can watch a quick summary of the keynote right here: https://youtu.be/wV8FVNy0yjc?si=7xAzDCXhx4LBN8W2.

The core takeaway from that presentation should terrify traditional digital marketers.

Search is no longer a directory of blue links pointing users to your website.

It has evolved into an autonomous operating system.

Google rolled out Gemini 3.5 Flash as the global default for AI Mode.

They introduced Information Agents that scour the web 24/7 while you sleep.

They deployed Generative UI powered by the Antigravity platform.

This means Google can now code interactive comparison tables and mini apps directly on the search results page.

If your current SEO strategy relies on churning out two thousand word blog posts to answer basic questions, your traffic is about to flatline.

AI Overviews are intercepting those queries before a user ever clicks a link.

But organic discovery is not entirely dead.

It has just mutated into Generative Engine Optimization.

The brands that survive will be the ones that stop optimizing for text strings and start optimizing for AI agents.

Here are five strategies to win this new game.

1. Target the High-Intent Micro-Queries

Top of funnel informational traffic is gone forever.

When a user asks how a mechanical watch works, Google does not need your blog post.

It will simply generate a 3D simulation or a concise explanation right on the results page.

The traffic that remains is mid-funnel and bottom-funnel.

These users already know their baseline problem.

They are looking for highly specific and complex solutions.

Generative AI models hallucinate when pushed into incredibly niche corner cases.

This is exactly where your brand must live.

Stop targeting broad terms like the best CRM software.

Start targeting how to integrate a custom Node.js CRM with legacy AS400 healthcare databases.

AI agents actively hunt for this deep and obscure expertise.

They need verified human experience to formulate complex answers.

When you answer the micro-questions your competitors ignore, you become the ultimate AI bait.

2. Treat Your Website Like an API

Google announced Information Agents that operate in the background around the clock.

A user can tell their personal agent to monitor the web for specific software pricing changes or local real estate trends.

These agents do not read your beautifully crafted prose.

They parse entities, relationships, and data structures.

If your content is buried in dense paragraphs, the agent will skip you.

It will cite a competitor who made their data easily readable instead.

You must treat your website like a database.

Implementing comprehensive Schema markup is no longer an optional task for your web developer.

It is the core infrastructure of modern search.

When AI agents assemble comparative answers, they look for structured and factual claims.

Format your content with clear question-based headers.

Provide direct and unformatted answers immediately below them before expanding on the topic.

3. Build Experiences AI Cannot Replicate

One of the most disruptive announcements at I/O 2026 was Generative UI.

Using the Antigravity engine, Google can now build custom user interfaces on the fly.

If a user wants to calculate mortgage amortization, Google will literally code a bespoke calculator in real time right in front of them.

If your website traffic relies on basic utility tools, you are competing directly with Gemini 3.5 Flash.

You cannot out-code Google.

Instead, you must harden your digital assets.

Inject proprietary first-party data into your tools that Google cannot access.

Build gated experiences.

Require user accounts to save complex progress states.

Add community features where users interact with each other in ways a bot cannot simulate.

You need to offer a digital experience that forces the user to leave the search engine.

4. Establish Undeniable Entity Trust

Large Language Models do not just look at what you publish on your own domain.

They look at who validates your expertise across the wider internet.

To an Answer Engine, your brand is an entity.

If that entity lacks citations from other trusted sources, the AI will not risk recommending you.

Digital PR and brand authority are the new backlinks.

You need the digital ecosystem talking about your brand in the exact same context as the hyper-specific content you publish.

When Gemini evaluates whether to include your product in a Universal Cart, it checks its training data for your historical reliability.

Publish content only genuine practitioners could write.

Include real case study data.

Use named authors with credentialed digital footprints.

Earn mentions in top-tier industry publications.

5. Pivot Hard into Multimodal Search

Text is losing its monopoly on search.

Google unveiled Ask YouTube.

This is a new conversational search experience that compiles interactive responses across all of YouTube.

Furthermore, the new Gemini Omni model possesses an intuitive understanding of physics.

It can seamlessly turn video, audio, or text into cohesive visual outputs.

If you are only producing text, you are missing out on the surfaces where discovery actually happens today.

Users are increasingly taking photos of their problems via Google Lens.

They are asking complex audio questions through smart eyewear.

Your brand must exist in video formats to be included in Ask YouTube syntheses.

Ensure all your proprietary visual assets carry proper metadata and verifiable credentials.

As Google pushes SynthID watermarking to combat deepfakes, original human-created video will carry a massive premium in trust signals.

The age of manufacturing authority through keyword density is over.

The new game is much harder to manipulate.

But it is infinitely more rewarding for brands that actually know what they are talking about.

Provide real expertise.

Structure it for machines.

Build experiences an AI cannot generate.

Read the full article on Forg →

Pause for a second. What if I told you talking to ghosts is now a $600 million industry?

Think back to that iconic Black Mirror episode where a grieving widow orders an exact synthetic replica of her dead husband. It felt like distant dystopian fiction.

Well, it is actually happening right now in China.

And the wildest part? The barrier between the living and the dead just got a paywall.

PS -If you prefer watching video instead reading. Watch here — https://youtu.be/er7FxJ44C0A?si=wwlrgRpnB1CDKC9y

We live in a world where we can barely get decent Wi-Fi in the subway, yet tech companies are figuring out how to let you FaceTime your deceased relatives.

Enter a startup called Superbrain. Based in Nanjing, this company takes whatever digital breadcrumbs you have left of somebody and builds an interactive replica.

They take photos, videos, and even random voice recordings of your loved one complaining about the weather. From there, they train an AI clone that looks, sounds, and talks exactly like them.

The terrifying part of the tech is how little it takes to make it work.

To create a voice clone, audio synthesis models only need about 30 seconds of clean audio. The neural networks extract the unique phonetic features, pitch, and cadence of the person.

For the visuals, computer vision engineers use a few photos to map out micro expressions. They combine this with Large Language Models (LLMs) trained on the deceased person's diaries, text messages, and chat histories. The LLM absorbs their exact thinking patterns and personality quirks.

Over 600 families have already done this. They are paying anywhere from $700 to $1,500 to revive their loved ones on a screen.

But there is an obvious glitch in this matrix. AI chatbots usually have the emotional warmth of a smart refrigerator.

Superbrain knows this. They understand that a hallucinating AI could psychologically break a grieving mother. So they actually pair the AI with a live, trained specialist. This human therapist works behind the scenes to guide the conversation in real time and ensure the emotional tone remains comforting.

Unfortunately, not every company in this space is playing nice.

The digital immortality market has essentially become the Wild West.

People are cloning celebrities without their consent. Some cemeteries in China are literally slapping QR codes on tombstones. You scan the grave with your phone, and a digital avatar of the deceased pops up on your screen to chat with you.

Then there is the corporate side of things. One company went as far as resurrecting a dead CEO to deliver a speech.

Imagine literally dying, leaving this earthly realm, and HR still makes you show up to the Q3 earnings meeting. Capitalism remains completely undefeated.

The demand for this "grief tech" is skyrocketing. China's digital cloning market hit an estimated $600 million in 2024 and it is growing by a massive 85% every single year.

It got so big so fast that the Chinese government had to step in.

The Cyberspace Administration of China just rolled out strict draft regulations. Under the new rules, all digital humans must carry visible labels so you know you are talking to software.

You also need explicit consent to use someone's likeness.

Most importantly, the government placed a strict ban on virtual intimate relationships for anyone under 18 years old.

When you zoom out and look at the big picture, a very clear pattern emerges.

We have AI companions. We have AI girlfriends. And now we have AI resurrections.

The emotional economy is exploding in real time.

We look at these hyper realistic avatars and marvel at the state of generative AI. We focus on the neural networks and the voice synthesis.

But maybe this trend is not really a story about how advanced our technology is getting.

Maybe it is just a dark reflection of how hopelessly lonely we have all become.

Read the full article on Forg →

Imagine scrolling through your feed and seeing a perfectly rendered, physics accurate video of yourself doing a backflip over a moving car.

You do not know how to backflip. You have never been near that car. But the lighting is flawless. The fluid dynamics of your jacket catching the wind look entirely real. Your voice sounds exactly like you.

This is no longer a multi million dollar Hollywood visual effects project. It is just another Tuesday on the internet, courtesy of Google’s new Gemini Omni model.

Unveiled at Google I/O 2026, Omni is an absolute monster of a generative engine. It allows users to drop themselves into any video, create hyper realistic AI avatars, and generate incredibly accurate footage from a single text prompt.

(By the way, if you want a rapid fire breakdown of everything else announced at Google I/O 2026, you can watch this short keynote recap right here: https://youtu.be/wV8FVNy0yjc?si=7xAzDCXhx4LBN8W2)

Handing the public an untethered reality distortion engine comes with a massive, society altering hangover. Deepfake incidents skyrocketed by a staggering 900 percent leading into this year.

With Omni making elite level video manipulation accessible to anyone with a smartphone, we are staring down a future where the vast majority of online media could be entirely synthetic.

Google knows it is handing out the matches. So, to prevent the digital world from burning down, they are rolling out the fire extinguishers.

The primary defense mechanism against this synthetic flood relies on two major pillars: C2PA credentials and the DeepMind SynthID watermark.

The Contradiction: Playing Both God and Cop

There is a profound irony at the heart of this technological leap. Google is simultaneously acting as the ultimate counterfeiter and the chief authentication officer.

They are creating the very tools that blur the line between fact and fiction. At the same time, they are desperately trying to build the infrastructure to tell us what is actually real.

Omni is a native multimodal system. Unlike older models that clumsily handed tasks from a text engine to an image engine and then to a video generator, Omni handles text, audio, image, and video simultaneously in one unified brain.

You can upload a video and edit it conversationally. You can tell it to dim the lights, change the camera angle, or turn a visible object invisible. The results are terrifyingly coherent.

To counteract the chaos this will inevitably unleash, Google is integrating deepfake detection directly into its most heavily used platforms.

Soon you will be able to right click an image in Chrome or use Circle to Search on your phone and simply ask a single question.

“Is this made with AI?”

But how does the system actually know?

The Defense: Metadata vs. The Pixel Deep Signal

Google’s verification strategy relies on a two layered approach, because relying on just one is a recipe for failure.

Layer 1: C2PA Content Credentials

Think of C2PA as a cryptographic nutrition label for digital media.

It is a piece of metadata attached to a file that logs a verifiable history of how the content was created and what tools were used. Google is pushing this hard, even expanding it deeply into Chrome and Search.

The problem with C2PA is fragility.

Malicious actors can strip metadata from files. Even worse, many social media platforms automatically compress uploads, which can unintentionally wipe that crucial nutrition label clean. A valid C2PA manifest might claim human authorship, but it does not certify the semantic truth of the image itself.

Layer 2: SynthID

This is where the real heavy lifting happens. Developed by Google DeepMind, SynthID is an invisible digital watermark embedded directly into the content itself.

In images and video, the watermark is baked into the visual spectrum at the pixel level.

In audio, the signal is hidden deep within the waveform.

In text, it slightly alters the token generation process, creating a statistical pattern that detectors can spot.

SynthID is built for war. It is designed to survive cropping, heavy filters, frame rate changes, and lossy compression. You cannot scrub it off without destroying the underlying media.

If someone takes a Gemini Omni video, runs it through an Instagram filter, compresses it on WhatsApp, and re uploads it to TikTok, SynthID will still ring the alarm bells when scanned by Google’s detection tools.

The Unwinnable Arms Race?

Google has already watermarked over 100 billion images and videos since SynthID first launched.

They are now bringing heavy hitters like OpenAI, Kakao, and ElevenLabs into the fold to standardize this invisible signal across the industry.

Yet the question remains: Can a watermark actually keep up with the sheer volume of AI generated media?

The hacker ethos of the internet naturally rebels against corporate tracking. Open source developers are already attempting to build models that bypass or scrub these invisible signals.

Furthermore, SynthID only flags content generated by participating models. If a bad actor spins up a rogue video generator on their local machine, it will not carry a Google watermark.

We are rapidly moving toward a two tiered internet.

On one side, we will have verified reality backed by C2PA sensor data and SynthID checks.

On the other side, we will have a vast ocean of unverified, highly persuasive synthetic content.

Google is handing us a tool that can quite literally reshape reality on a whim. SynthID is a brilliant piece of engineering, but expecting it to single handedly save the true internet might be asking too much.

The technology can flag the deepfakes, but it is ultimately up to us to care whether the video we are watching actually happened.

Read the full article on Forg →

Prefer video instead of reading?

https://youtu.be/e1-gDwmKTa8?si=ev-AD9vT93J8fd0L

So, GitHub got hacked.

And I don’t mean a random user left their password on a sticky note, or a third-party integration leaked a few tokens. I mean GitHub’s own internal code repositories  and  the crown jewels of the company that basically runs the world’s version control  were stolen.

As of May 20, 2026, the investigation is still actively running. But what we already know paints a terrifying picture of modern software security. The entry point wasn’t a sophisticated, nation-state zero-day exploit.

It was a VS Code extension.

How 11 Minutes Broke the Perimeter

The breach started with an almost painfully boring action: a GitHub employee installed a poisoned VS Code extension.

That single installation gave the attacker access to the employee’s workstation. From there, they pivoted directly into GitHub’s internal network, exfiltrating roughly 3,800 internal repositories. The group claiming credit, a cybercrime outfit known as TeamPCP (also tracked as UNC6780), has already listed the dataset on underground forums for upwards of $50,000. If no one buys it, they plan to leak it.

GitHub reacted quickly. They isolated the infected device, ripped out the malicious extension, and spent the night rotating high-impact credentials. They’ve stated that customer repositories and enterprise accounts remain unaffected, but when it comes to the 3,800 internal repos  and proprietary platform source code, internal tooling, and organizational files — the damage is done.

But here is the detail most people are missing: the speed of the attack.

The day before GitHub confirmed their breach, the popular Nx Console VS Code extension (which boasts over 2.2 million installs and a verified publisher badge) was briefly backdoored.

The Stolen Token

Prior to May 18

An Nx contributor’s GitHub personal access token is scraped during a separate, earlier supply chain incident.

The Orphan Commit

May 18, 03:18 UTC

The attacker uses the stolen token to push a “dangling orphan commit” to the official nrwl/nx repo. It contains a 498 KB obfuscated payload hidden inside an index file.

The Poisoned Publish

May 18, 12:36 UTC

Using stolen VS Code Marketplace credentials, the attacker publishes nrwl.angular-console v18.95.0. It contains just 2,777 bytes of malicious code injected into main.js.

The Takedown

May 18, 12:47 UTC

The Nx team detects the rogue publish and yanks it from the marketplace.

The poisoned extension was live for exactly 11 minutes.

That sounds like a win for the community, right? Wrong. If you are a developer who opened your editor during that 11-minute window, and you had auto-update turned on, your machine downloaded the payload silently.

The Mini Shai-Hulud Worm

The payload dropped by these attacks isn’t just a simple script. TeamPCP utilizes a highly sophisticated, automated worm known as Mini Shai-Hulud.

Once it lands on a developer’s machine, it acts as a multi-stage credential stealer. It doesn’t just look for GitHub tokens; it rummages through your local environment for everything it can find. It checks .env files, extracts 1Password vaults, scrapes AWS keys, and even targets AI coding assistant configurations like Anthropic's Claude.

Worse, if it finds CI/CD credentials, the worm uses them to publish infected versions of other packages downstream, perpetuating the supply chain attack. It’s automated, ruthless, and terrifyingly efficient. In earlier attacks, it even carried a disk-wiping module that acted like Russian Roulette, wiping the rm -rf /* directory if certain geolocation conditions were met.

A Pattern, Not an Anomaly

If you think this was just a streak of bad luck for GitHub, zoom out. This is the third major GitHub-related security event in six weeks.

1. Late April (CVE-2026–3854): Wiz researchers uncovered a critical remote code execution (RCE) flaw in GitHub’s internal Git infrastructure. By exploiting an injection flaw via a simple git push command, attackers could execute arbitrary commands on backend servers. GitHub patched it in hours for GitHub.com, but at the time of writing, roughly 88% of GitHub Enterprise Server (GHES) instances are still vulnerable.

2. May 16 (Grafana Labs): The “CoinbaseCartel” group stole Grafana’s entire private source code, extorting them after slipping in through a compromised GitHub token obtained via a CI/CD pipeline vulnerability.

3. May 20: GitHub itself is breached via a VS Code extension.

The Real Problem: Your Laptop is the Perimeter

The uncomfortable truth exposed by the May 2026 GitHub hack is that the security perimeter no longer ends at the datacenter door or the cloud firewall. It ends on the developer’s laptop.

If you’re an engineer, your machine is a goldmine. You have production credentials, staging access, and AWS keys. And yet, that exact same machine runs whatever extensions you install from a marketplace where, practically speaking, anyone can publish. High install counts and “verified” badges are no longer guarantees of safety and  they are the exact signals attackers target to maximize their blast radius.

GitHub is one of the best-resourced engineering companies on the planet. Their incident response was stellar: they identified the breach, isolated the endpoint, rotated keys, and went public in a matter of hours. But it still happened to them.

What You Need to Do Right Now

Whether you are a solo dev or managing an enterprise team, you need to lock down your local environment immediately.

1.Disable VS Code Auto-Update:

This is the most critical fix. Auto-update guarantees that a poisoned payload gets installed the second you open your editor. Turn it off. Give the community time to spot malicious updates before you pull them down.

2.Audit Your Extensions:

Go to your extensions list. If you installed a random formatter three years ago for a weekend project, delete it. If an extension has 100 installs and was created two weeks ago, delete it. Keep your editor lean.

3.RotateThe Stolen Token

Prior to May 18

An Nx contributor's GitHub personal access token is scraped during a separate, earlier supply chain incident

Your GitHub Tokens:

It takes five minutes. If any of those 3,800 stolen internal repos contained tokens that could interact with the broader GitHub API, you want your credentials to be fresh and disconnected from any historical leaks.

4.Patch Enterprise Server (Admins Only):Critical fix for CVE-2026–3854.

If you are running GHES, upgrade to version 3.19.3 immediately. Eight out of ten instances are still vulnerable to a single malicious git push.

The era of blindly trusting developer tooling is over. When the tools we use to build software become the weapons used to dismantle it, the only defense is zero trust  and starting with your own code editor.

Read the full article on Forg →

Most Chatbots Have Goldfish Memory. Here's How to Fix That in 30 Lines of Python.

You ask a chatbot something. It answers. You follow up. It has no idea what you just talked about.

That's not a conversation. That's a search bar with extra steps.

The fix is not complicated. Here's how to build a conversational agent that actually remembers what you said, using LangChain and GPT-4o-mini.

What we're building

A chat agent that maintains conversation history across messages. Ask it something, follow up, and it knows exactly what you said before. The whole thing is about 30 lines of code.

Four moving parts:

• A language model to generate responses

• A prompt template that structures each conversation

• A history manager that handles what gets remembered

• A message store that keeps each session separate

Setup

Install the dependencies:

pip install langchain langchain_experimental openai python-dotenv langchain_openai

Then the imports:

from langchain_openai import ChatOpenAI
from langchain_core.runnables.history import RunnableWithMessageHistory
from langchain_community.chat_message_histories import ChatMessageHistory
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
import os
from dotenv import load_dotenv

load_dotenv()
os.environ["OPENAI_API_KEY"] = os.getenv('OPENAI_API_KEY')

Initialize the model

llm = ChatOpenAI(model="gpt-4o-mini", max_tokens=1000, temperature=0)

temperature=0 keeps responses consistent and predictable. Good default for most use cases.

Build the message store

This is where conversation history lives. Each user gets their own session, identified by a session_id.

store = {}

def get_chat_history(session_id: str):
    if session_id not in store:
        store[session_id] = ChatMessageHistory()
    return store[session_id]

Simple dictionary. Session doesn't exist yet? Create it. Already exists? Return it. That's the whole thing.

This means you can run ten different conversations simultaneously and they won't bleed into each other.

Create the prompt template

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful AI assistant."),
    MessagesPlaceholder(variable_name="history"),
    ("human", "{input}")
])

Three parts: a system message that sets the AI's behavior, a placeholder where the conversation history gets injected, and the user's current message.

The MessagesPlaceholder is the important bit. Every time you send a new message, LangChain fills that slot with the full conversation history automatically. You don't manage this manually.

Wire it together

chain = prompt | llm

That pipe operator chains the prompt into the model. Prompt renders first, output goes into the model.

Now wrap it with history management:

chain_with_history = RunnableWithMessageHistory(
    chain,
    get_chat_history,
    input_messages_key="input",
    history_messages_key="history"
)

RunnableWithMessageHistory is doing the heavy lifting here. It intercepts every call, fetches the right session history, injects it into the prompt, runs the chain, and saves the new messages back to the store. You don't write any of that logic yourself.

Use it

session_id = "user_123"

response1 = chain_with_history.invoke(
    {"input": "Hello! How are you?"},
    config={"configurable": {"session_id": session_id}}
)
print("AI:", response1.content)

response2 = chain_with_history.invoke(
    {"input": "What was my previous message?"},
    config={"configurable": {"session_id": session_id}}
)
print("AI:", response2.content)

Output:

AI: Hello! I'm just a computer program, so I don't have feelings, 
but I'm here and ready to help you. How can I assist you today?

AI: Your previous message was, "Hello! How are you?" 
How can I assist you further?

It remembered. That's the whole point.

You can inspect the full history at any point:

print("\nConversation History:")
for message in store[session_id].messages:
    print(f"{message.type}: {message.content}")

Conversation History:
human: Hello! How are you?
ai: Hello! I'm just a computer program, so I don't have feelings...
human: What was my previous message?
ai: Your previous message was, "Hello! How are you?"...

What this does not handle

This stores history in memory. The moment your process restarts, it's gone. For anything production-facing you'd swap ChatMessageHistory for a persistent store like Redis or a database. LangChain has built-in integrations for both.

Long conversations also get expensive fast. The entire history gets sent with every message. At some point you'll want to summarize older messages instead of passing them verbatim. But that's a problem for when your conversations actually get long.

Where to take it next

The foundation works. From here you can point it at your own data with a vector store, give it tools like web search or calculator access, or swap the system prompt to give it a specific persona or domain expertise.

The context management pattern stays the same regardless. That's why it's worth getting right first.

Read the full article on Forg →

Every company markets. No exceptions. The Fortune 500, the two-person startup, the plumber in Ohio who just got a website. Everyone is in this game.

The global martech market is a trillion dollars. And it still runs on spreadsheets, agency retainer calls that go nowhere, and attribution dashboards built to make marketers feel busy rather than informed.

The spend is real. B2B companies throw 5 to 10% of revenue at marketing. Consumer brands often double that. And most of them, if you pushed them in a room and asked what's actually working, would stare at the floor.

That's not a problem. That's a trillion-dollar opening.

Here's where I think it goes.

1. The AI CMO Nobody Can Afford to Hire

Here's the dirty secret of sophisticated marketing: it was always pay-to-play.

You either hired a CMO at $300K, paid an agency $8K a month to give you recycled strategy in a Notion doc, or you winged it. Most companies winged it. The Fortune 500 bought the real thing. Everyone else bought the illusion of the real thing.

That two-tier system is ending.

What's coming is a persistent AI operator that monitors competitor moves, runs campaign variants, reallocates budget when signals shift, and delivers a weekly strategic brief. No vacation. No "let's circle back." No invoice.

The wedge isn't the technology. The wedge is the 50,000 companies doing $5M to $50M in revenue that always needed a CMO and could never justify one. That's the market. It's enormous and almost entirely unserved.

2. Content as a Weapon, Not a Calendar

Content marketing has one historical constraint: humans are slow.

A blog post took a day. A video took a week. Localising for three markets took long enough that the campaign was already irrelevant by launch. Ambition was never the limit. Throughput was.

That's over.

When generating a hundred SEO pages costs roughly what generating one used to cost, the game changes completely. You stop asking "what should we publish?" You start asking "what are we testing this week and what did we kill last week?"

The brands winning at this aren't producing more content. They're running content like a performance loop. Generate, deploy, measure, kill the losers, pour fuel on the winners, repeat. It's not a content team. It's a content engine.

The builders who grasp this first aren't going to catch up. They're going to compound. That's a different thing entirely.

3. Knowledge is the Moat Nobody's Talking About

Here's something the marketing conversation keeps skipping over.

AI can generate campaigns. What it can't generate is context. The institutional memory of what worked, why it worked, which message landed with which segment, what decision was made six months ago and why. That knowledge lives in Slack threads, old decks, and the heads of people who quit.

This is the problem Syncally is built to solve, a knowledge layer that connects decisions to outcomes across the entire team. Not just for marketing but for any function where institutional memory is the difference between compounding and starting over every quarter.

The companies that build internal knowledge infrastructure win the long game. The ones that don't keep relearning the same lessons at increasing cost.

4. Personalisation at a Scale That Was Previously Insane to Attempt

Mass advertising is a blunt instrument. You pick a segment, write one message, launch, and hope. The whole industry is built on the assumption that speaking to people differently at scale is too expensive to be worth it.

That assumption is now wrong.

We are moving into a world where you run 400 campaign variants across 60 audience segments and the system figures out what to scale before any human has reviewed the data. Not "we A/B tested two headlines." Genuinely different creative, different offers, different funnels, different channels, all adapting in real time.

The business case is brutal in its clarity. Average e-commerce conversion efficiency is down 15 to 20% from three years ago. Everyone is fishing the same water. You cannot outspend the incumbents. But you can out-target them, if you build the infrastructure to do it.

The personalisation layer that sits above the platforms, unifying creative intelligence, audience modelling, and spend allocation, that's still wide open.

5. The Attribution Problem Nobody Has Actually Solved

Ask any CMO why CAC jumped 30% last quarter. Watch what happens.

You'll get a deck. The deck will have charts. The charts will show channel breakdowns, impression counts, click-through rates. None of it will actually answer the question.

Attribution is the promised land of martech. Twenty years of multi-touch models, media mix modelling, incrementality testing. All valuable. All partial. None of them connecting paid, organic, social, email, and product usage into a single coherent picture of what's actually driving revenue.

This isn't a tooling failure. It's an architecture failure. The data exists. It just doesn't talk to itself.

The company that builds always-on revenue intelligence, something that tells an exec not just what happened but what a competitor did last week that's about to show up in your numbers next month, that company has enterprise-grade switching costs from day one. You don't rip out your Bloomberg Terminal. You just keep paying for it.

6. Developers Are Builders, and Builders Market Differently

There's a segment in this whole conversation that gets ignored: the indie builders, the developer-led products, the one-person SaaS companies shipping faster than most VC-backed teams.

These people don't have marketing budgets. They have audiences. They build in public, they share what they're making, and the product is the marketing.

Forg.to exists for this exact reason. A single developer profile that pulls together everything a builder ships, across GitHub, dev.to, YouTube, product launches, and everything else, into one place. The profile is the distribution. The consistency is the moat.

This segment is growing fast and it doesn't need a CMO. It needs infrastructure that turns building into an audience. That's a different product category, and it's early.

The Real Point

Google and Meta will absorb some of this. They always absorb the obvious layer.

But there's always a durable intelligence layer above the platforms where independent companies compound real advantages. The history of enterprise software is proof. The platforms win the pipes. Independent companies win the brain.

Marketing is turning from a department into a programmable system. That system's operating system hasn't been written yet.

The ROI on smart marketing is staggering. The proof is right in front of us. Dumb marketing already generates billions. What happens when it actually works?

Build now. The window is open.

Read the full article on Forg →

Product Hunt is still the default choice for launching a product. It can bring traffic, feedback, and visibility if things go well. But most founders eventually realize a few limitations:

• You only get one launch day: After 24 hours, your product falls off the front page and effectively "dies" in terms of discovery.

• Competition is extremely high: You are often competing with VC-backed startups for the #1 spot.

• Results depend on luck: Success is heavily tied to timing, your existing network, and the specific mood of the algorithm that day.

Because of this, many builders are looking beyond the "one-day spike" model. Here is a practical breakdown of platforms where you can showcase your product today, starting with the one
that is fundamentally changing how products grow.

forg.to

forg.to (https://forg.to) is not just a "launch platform" but it’s a growth engine for builders who are in it for the long haul.

While other platforms focus on creating 24 hours of hype that quickly fades, forg.to is designed for the entire lifecycle of your product. It solves the biggest problem in shipping: the
"post-launch silence."

Why it makes everything else look outdated:

• Continuous Momentum: Instead of one single launch day, you keep adding updates, features, and ideas. Every time you ship a small improvement, you get fresh feedback and visibility.

• The Living Changelog: Every update you post creates a beautiful, professional timeline of your product’s evolution. This isn't just a list; it’s proof of progress that builds massive
  trust with users.

• Portable Visibility: You can plug your forg.to timeline anywhere as an embed or an RSS feed. Your "Build in Public" journey can live on your own landing page or blog automatically.

• Feedback Loops: You don't just "show" your product; you get feedback on every specific feature update or announcement as they happen, not just once at the start.

Where it fits: It is your primary home for building in public. Use it to turn a one-time launch into a permanent, growing presence.

Peerlist

Peerlist is a mix of a professional network and a launch platform. It combines elements of LinkedIn and Product Hunt, creating a space specifically for builders.

What works well:

• You get a full week for your launch instead of just one day.

• There is a strong builder community, particularly active in the indie-maker space.

• Consistent posting can drive organic traffic to your product over time.

The catch:

• If your product isn't featured, visibility is limited.

• It requires high daily activity to stay relevant.

BetaList

BetaList focuses on early-stage startups and is designed for founders who want feedback before a full-scale public launch.

What works well:

• Audience consists primarily of early adopters and "testers."

• Great for validating a value proposition before investing in heavy marketing.

• It has a long history and a trusted reputation.

The catch:

• You have very little control over when your product goes live.

• The approval process can take weeks unless you pay for a skip-the-queue option.

StartupBase

StartupBase is more of a directory than a high-octane launch platform. It provides long-term discoverability rather than a single event.

What works well:

• Excellent for building high-quality backlinks and improving SEO.

• Simple, straightforward submission process.

• Listings bring in steady, "background" traffic over months and years.

The catch:

• There is zero "launch momentum." You won't see a massive spike in users on day one.

• Low community engagement compared to interactive platforms like forg.to.

Final Thoughts

Product Hunt is a great "event," but it shouldn't be your only strategy.

The biggest mistake founders make is treating their product like a movie premiere and all the noise happens on day one, and then it’s forgotten. forg.to fixes this by allowing you to build a
permanent, evolving presence where every update is a new opportunity to be discovered.

If you are building something for the next few years, don't just launch it but forg it. Use the other platforms for spikes, but use forg.to for the long run.

Read the full article on Forg →

Two hours of my life spent assuming there was a GPU cluster somewhere running an image classifier.

There wasn't.

It's reading metadata. That's it. And I shipped the same thing on forg.to in an afternoon with zero new dependencies and zero added cost.

Here's the actual story.

Why forg.to needed this

forg.to is where indie hackers and builders share their product journey. Real wins, real losses, real progress.

As AI image generation got good, posts started showing up with suspiciously polished mockups. Nobody was lying. But context was missing. Was this a real screenshot or a Firefly render?

I wanted a small badge on AI-generated images. Hover over it, see which tool made it. Transparent, automatic, zero friction for the person posting.

Two hard constraints going in: the site stays fast, and this costs nothing. Those two constraints ruled out almost every obvious solution.

So I went digging into how the badge actually works.

C2PA: the boring open standard doing all the work

There is an open standard called C2PA, backed by Adobe, Microsoft, Google, OpenAI, and others. The basic idea: when an AI tool generates an image, it embeds a cryptographically signed manifest into the file recording how the image was made, which tool made it, and when.

This manifest travels with the file. Download it, share it, post it anywhere. The manifest stays embedded.

The official way to read these manifests is a library from Adobe called c2pa-js. It uses WebAssembly to parse them in the browser. Capable, well-documented, and 1.5MB of WASM.

I almost used it. Then I asked: what does that WASM actually buy me?

Full cryptographic verification of the provenance chain. Genuinely useful for Adobe's enterprise customers and publishers worried about deepfakes.

For a community feed? I just need to know: was this image made by an AI tool? I don't need to verify the cryptographic signature. I need to read a text field.

That's when I looked at what C2PA actually writes to the file.

It's just XMP

JPEG and PNG files are not just pixel data. They carry metadata segments, chunks of text embedded alongside the image data. The most common format is XMP, a subset of XML written into an APP1 marker segment near the start of most image files.

XMP is how Lightroom stores your star ratings. How your phone records GPS coordinates. And how C2PA-compliant AI tools record their provenance.

Open a DALL-E 3 generated image in a hex editor. Scroll past the JPEG header. You'll find something like this:

<?xpacket begin="..."?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
  <rdf:RDF xmlns:rdf="...">
    <rdf:Description xmlns:c2pa="http://c2pa.org/schema/c2pa/1.1/">
      <c2pa:claim_generator>c2pa-rs/0.28.0 OpenAI/1.0</c2pa:claim_generator>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>

That http://c2pa.org namespace is the fingerprint. If it's there, the image has Content Credentials.

Even AI tools that don't implement full C2PA often write standard XMP fields:

<xmp:CreatorTool>Adobe Firefly</xmp:CreatorTool>
<photoshop:Source>Adobe Generative Fill</photoshop:Source>

No WASM. No cryptography. No external library. Just ArrayBuffer, TextDecoder, and a regex.

The implementation

I created src/lib/utils/detectAiImage.ts. A standalone function that takes a File and returns whether it's AI-generated and which tool made it.

typescript

export async function detectAiImage(file: File): Promise<AiImageDetails | null> {
    try {
        const slice = file.slice(0, 65536); // Read first 64KB only
        const buffer = await slice.arrayBuffer();
        const raw = new TextDecoder("latin1").decode(buffer);

        const start = raw.indexOf("<?xpacket begin");
        if (start === -1) return null;
        const end = raw.indexOf("<?xpacket end", start);
        const xmp = end !== -1 ? raw.slice(start, end + 40) : raw.slice(start, start + 32768);

        if (xmp.includes("c2pa.org") || xmp.includes("contentauth")) {
            const generator =
                extractText(xmp, "claim_generator") ??
                extractText(xmp, "CreatorTool") ??
                extractText(xmp, "Software");
            const toolName = generator ? (matchAiTool(generator) ?? generator.slice(0, 50)) : undefined;
            return { isAi: true, toolName };
        }

        const candidates = [
            extractText(xmp, "CreatorTool"),
            extractText(xmp, "Software"),
            extractText(xmp, "Generator"),
            extractText(xmp, "Source"),
        ].filter(Boolean) as string[];

        for (const val of candidates) {
            const toolName = matchAiTool(val);
            if (toolName) return { isAi: true, toolName };
        }

        return null;
    } catch {
        return null;
    }
}

Three decisions worth explaining:

Why latin1 encoding? XMP is UTF-8 XML, but we're reading a binary JPEG that mixes binary pixel data with text metadata. Latin-1 maps every byte 0-255 to a Unicode code point 1:1, so indexOf and slice work correctly across both sections without byte corruption. We only care about ASCII characters in the XMP namespace URLs anyway.

Why 64KB? XMP always appears in the first APP1 segment of a JPEG, right after the SOI marker. It's virtually always within the first few kilobytes. 64KB is generous headroom for unusual files while reading about 1% of a typical 5MB image.

Why file.slice()? File.slice() creates a new Blob pointing to the same underlying buffer. It doesn't copy bytes. The arrayBuffer() call only reads those 64KB. For a 10MB image, we process 0.6% of it.

The matchAiTool function tests the extracted string against known patterns:

typescript

const AI_TOOL_PATTERNS = [
    { pattern: /firefly/i,               name: "Adobe Firefly" },
    { pattern: /dall[-\s]?e/i,           name: "DALL-E" },
    { pattern: /midjourney/i,            name: "Midjourney" },
    { pattern: /stable[\s-]?diffusion/i, name: "Stable Diffusion" },
    { pattern: /image\s*creator/i,       name: "Microsoft Image Creator" },
    { pattern: /generative\s*fill/i,     name: "Adobe Generative Fill" },
    { pattern: /canva/i,                 name: "Canva AI" },
    { pattern: /ideogram/i,              name: "Ideogram" },
    { pattern: /flux/i,                  name: "Flux" },
];

If no pattern matches but the image has a C2PA namespace, we still show the raw claim_generator value truncated to 50 characters. That way we don't silently drop data from tools we haven't added yet.

The timing problem that would have broken everything

forg.to compresses images before uploading. Before any image hits Cloudinary, it goes through a canvas-based compressor that re-renders it at reduced quality.

When a JPEG goes through canvas.toDataURL(), it becomes a new JPEG. The canvas knows nothing about XMP. It writes pixels. All metadata is gone.

So detection has to happen before compression, on the original File object, the moment the user selects it.

This is where we hook in:

typescript

let insertOffset = imageFiles.length;

for (const file of files.slice(0, 4 - imageFiles.length)) {
    if (!file.type.startsWith("image/")) continue;

    setImageFiles((prev) => [...prev, file]);
    setImagePreviews((prev) => [...prev, URL.createObjectURL(file)]);

    const idx = insertOffset++;
    setImageAiDetails((prev) => [...prev, null]);

    import("@/lib/utils/detectAiImage").then(({ detectAiImage }) =>
        detectAiImage(file).then((result) =>
            setImageAiDetails((prev) => {
                const next = [...prev];
                next[idx] = result;
                return next;
            })
        )
    );
}

The dynamic import() is intentional. The detection module loads lazily, only the first time a user opens the composer and picks an image. It adds zero bytes to the initial JS bundle. Subsequent detections use the cached module.

The insertOffset variable solves a subtle race condition: if a user selects three images at once, imageFiles.length reads the same stale value across all three loop iterations because React batches state updates. Tracking the offset manually gives each file the correct array index.

Detection runs async without blocking the UI. If a file has no XMP or the scan throws, null is stored and no badge appears. Silent failures are correct behavior for an optional feature.

Persisting it through the stack

Detection is useless if we throw the result away before saving the post.

The type:

typescript

media?: {
    type: "image" | "video" | "gif";
    url: string;
    aiDetails?: { isAi: boolean; toolName?: string };
}[];

The Mongoose schema:

typescript

media: {
    type: [{
        type: { type: String, enum: ["image", "video", "gif"] },
        url: String,
        aiDetails: {
            isAi: { type: Boolean },
            toolName: { type: String },
        },
    }],
    default: [],
},

No migration needed. MongoDB handles new optional fields on existing documents gracefully. Documents without aiDetails just return undefined, and the badge code already guards against that with optional chaining.

The crosspost service merges AI details into each media object at write time:

typescript

if (mediaUrls && mediaUrls.length > 0) {
    updateData.media = mediaUrls.map((url, i) => ({
        type: 'image',
        url,
        ...(mediaAiDetails?.[i] ? { aiDetails: mediaAiDetails[i] } : {}),
    }));
}

If there are no AI details, the field is simply not written to the document. No aiDetails: null noise in the database.

What this actually costs

SurfaceCostInitial page load0ms, 0KB. The utility is never imported until the composer opens.Feed rendering~0ms. A conditional div and a Tooltip, only rendered if aiDetails.isAi is true.Image selection (first time)20-50ms. Module import plus reading 64KB from a local File object.Image selection (after first)5-15ms. Module is cached, just the file read.Database~0ms overhead. Two optional fields on an existing document, no new indexes.

The 20-50ms on first image selection runs off the main thread on the async microtask queue. The user sees zero visual delay.

What it catches and what it doesn't

Detected: any image with a c2pa.org XMP namespace, DALL-E 3, Adobe Firefly, Adobe Generative Fill, Midjourney (when exported with metadata), Stable Diffusion (with metadata-preserving exporters), Microsoft Image Creator, Canva AI, Ideogram, Flux, and anything new via the raw claim_generator fallback.

Not detected: screenshots of AI images (a screenshot is a new file, no XMP from the original), images run through a compressor or re-saved before posting, AI images from tools that don't write C2PA or XMP metadata.

This is the same fundamental limitation any metadata-based approach has. The honest framing: this is a transparency signal for users who generated an image and posted the original file. It's not a detection system for bad actors. Anyone who wants to hide the origin can screenshot it. But users who just generated something with Firefly and posted it directly? They get the badge automatically, without doing anything.

That's the right tradeoff.

The final diff

6 files. ~150 lines. Zero new dependencies. Zero cost. Zero performance impact.

The engineering instinct when you see a polished feature on a big platform is to assume there's a serious ML pipeline behind it. Sometimes there is. Often, though, the interesting features are built on boring standards that have been sitting in files on your hard drive for years.

C2PA isn't new. XMP isn't new. JPEG metadata segments aren't new. What changed is that major AI labs started writing to them, because an open standard for provenance is genuinely in everyone's interest as AI-generated content becomes ubiquitous.

We got this feature for free by reading what those tools already wrote.

Next time you see something on a big platform and think "that must require serious infrastructure," open the spec. Sometimes it's just a text file inside a JPEG.

Read the full article on Forg →

You ship a feature. You post about it on forg.to. Then you open your website changelog and do it all over again.

That's the problem. You're writing the same update twice, for two different audiences, and the second time is just busywork. forg.to already has your updates. Your website should just... show them.

Here are three ways to make that happen. Pick whichever fits.

Method 1: Embed Widget (60 seconds, zero code)

Go to your product on forg.to, hit Share, then Embed. Pick a theme and accent color, copy the iframe, drop it wherever your changelog section lives.

<iframe
  src="https://forg.to/embed/your-product?theme=dark&accent=%2310b981"
  width="100%"
  height="420"
  frameborder="0"
 
></iframe>

It shows your 5 latest updates, your logo, tagline, and upvote count in a timeline layout. Every time you post on forg.to, the embed updates. You do nothing else.

Theme options: dark or light. Five prebuilt color presets (Classic, Night, Creator, Minimal, Warm), or pass any hex code to match your brand.

Method 2: Announcement Banner (even less work)

No changelog page? Don't want one? This is for you.

Paste a small script tag into your site's <head>. It fetches your latest update and injects a dismissible banner at the top or bottom of every page.

<script>
(function(){
  var s="your-product", t="dark", a="#10b981", p="top";
  fetch("https://forg.to/api/embed/"+s+"/latest")
    .then(function(r){ return r.json() })
    .then(function(d){
      // creates the banner, handles dismiss, cleans itself up
    });
})();
</script>

The smart bit: it uses localStorage to track which update each visitor has seen. Post something new on forg.to and the banner surfaces again for everyone. One post, automatic nudge to your whole user base. You choose "top" or "bottom". That's the only decision.

Method 3: The API (if you want full control)

If you want your changelog to look exactly like the rest of your site and don't want to deal with an iframe, use the public API. It's read-only JSON, CORS-open, and takes about 20 lines to wire up.

GET https://api.forg.to/v1/products/{your-slug}/updates
Authorization: Bearer YOUR_API_KEY

Full Next.js example:

// app/changelog/page.tsx

async function getUpdates() {
  const res = await fetch(
    'https://api.forg.to/v1/products/your-slug/updates',
    {
      headers: { Authorization: `Bearer ${process.env.FORG_API_KEY}` },
      next: { revalidate: 3600 },
    }
  );
  if (!res.ok) return [];
  return (await res.json()).updates;
}

export default async function ChangelogPage() {
  const updates = await getUpdates();
  return (
    <main>
      <h1>What's New</h1>
      {updates.map((u) => (
        <article key={u.id}>
          <time>{new Date(u.createdAt).toLocaleDateString()}</time>
          <h2>{u.title}</h2>
          <p>{u.content}</p>
          {(Date.now() - new Date(u.createdAt)) / 86400000 < 7 && (
            <span>New</span>
          )}
        </article>
      ))}
    </main>
  );
}

Full styling control, your component structure, no iframe quirks. Rate limit is 100 req/min, which is more than enough for a changelog page.

What you get out of this

• Your website changelog updates every time you post on forg.to. You write it once.

• Visitors see that your product shipped something last Tuesday. That builds trust quietly.

• Regularly updated content is good for SEO. A self-updating changelog compounds over time without any extra effort.

The point is simple: you were already writing these updates. Now they just go to two places instead of one.

Sign up at forg.to, post your first update, and pick any method above. You're done in under five minutes.

Read the full article on Forg →

You're Paying for Claude. You're Also Wasting Most of It.

I used to hit my usage limit by 2pm every day.

Not because I was doing too much work. Because I had no idea how Claude actually charges you.

Once I understood the real mechanic, everything changed. I now hit my limit maybe once a month.

Here is what nobody tells you upfront.

The one thing you need to understand first

Claude does not read just your latest message.

Every time you send a message, Claude re-reads the entire conversation from the top. Message 1. Message 2. All the way to where you are now. Every single time.

So message 1 costs almost nothing. Message 30 means Claude just re-read 29 full exchanges before even thinking about what you asked.

That is where your credits go. Not to your questions. To the history behind them.

Every habit in this article comes back to one idea: stop paying to re-read things that no longer matter.

The habits most people don't know about

1. Convert files before uploading them

A single PDF page costs between 1,500 and 3,000 tokens. A screenshot can cost 1,300 tokens. DOCX and PPTX files carry invisible metadata bloat on top of that.

The fix takes two minutes. Open a blank Google doc (type doc.new in your URL bar), paste only the text you actually need, download it as a .md file, and upload that instead.

If you upload the same 15-page PDF to four different chats, you just burned over 180,000 tokens on a document that could have been 2,000 tokens of clean text.

2. Plan in chat. Build in Cowork.

File creation, spreadsheets, decks, and documents cost more than regular chat messages.

So do not open Cowork and say "create me a financial model."

Open Chat first. Plan the structure. Agree on sections. Nail the assumptions. Once you know exactly what you want, move to Cowork and say "build this exact thing."

Thinking is cheap. Building is expensive. Do them in the right order.

3. Say "ask me questions" instead of writing long prompts

A 500-word prompt costs 500 tokens every time Claude re-reads the conversation. A 15-word prompt that triggers clarifying questions costs almost nothing.

The prompt I use for 80% of sessions: "I want to [task] to achieve [goal]. Ask me questions before you start."

Clicking options costs almost nothing. Typing paragraphs costs a lot. Let Claude pull the context out of you instead of you pushing walls of text at it.

4. Stop asking Claude to redo the whole thing

When section 3 of a report is wrong, do not say "redo the report."

Say "only redo section 3. Keep everything else."

Every full redo means Claude regenerates the entire output. If the report is 2,000 tokens, that is 2,000 output tokens burned again. Point to the specific problem. Fix only that.

Also: add "no commentary, no explanations, just the output" when you know exactly what you want. Every sentence of "Happy to help! Here is what I did..." is tokens you are paying for.

5. Edit your message instead of sending a follow-up

This is the one that changed my daily usage most.

In Chat, you can click Edit on your previous message, fix it, and regenerate. The old exchange gets replaced, not stacked.

Every time you type "no, I meant..." or "actually, change X to Y," you are adding to the history Claude re-reads forever. The edit button removes that entirely.

6. Batch your tasks into one message

Three separate prompts equal three full context reloads.

One prompt with three tasks equals one reload.

Instead of sending "summarize this," then "list the main points," then "suggest a headline" as three messages, write them all in one. The answer is usually better too. Claude sees the full picture at once.

7. Use the right model for the task

Opus with extended thinking is heavy machinery. Do not use heavy machinery to move a chair.

Grammar checks, brainstorming, reformatting, quick answers: Sonnet handles all of this at a fraction of the cost.

My rule: if the task takes Claude under 30 seconds to answer, it does not need Opus. Switch before you start. It takes two clicks.

8. Keep your context files short

If you use Cowork with a personal context file, Claude reads it before every single task. If that file is 10,000 words, that is thousands of tokens burned before any real work starts. Every session.

Keep it under 2,000 words. Cut anything that does not change how Claude writes or decides.

9. Restart the conversation instead of correcting

A 20-message Cowork session burns roughly 105,000 tokens. A 30-message session burns 232,000.

When a session goes sideways, do not keep correcting forward. Restart from an earlier message, or start a completely fresh session with a one-line summary of what you need.

Clean slate is almost always cheaper than digging out.

10. New topic, new chat. Always.

If you asked about a LinkedIn post, then a client proposal, then something else, all inside the same chat, Claude is still re-reading the LinkedIn conversation while thinking about the new topic.

Old messages are dead weight. Tokens spent on context that does nothing.

New topic equals new chat. Every time.

11. Use Projects for documents you reference often

If you upload the same PDF to five different chats, Claude re-reads that document five full times.

Use Projects instead. Upload once. Every conversation inside that project references it without burning fresh tokens. If you work with contracts, brand guides, or research papers you reference often, this alone can cut your usage significantly.

12. Turn off features you are not using

Web search, connectors, and extended thinking all add tokens to every response, even when you do not need them.

My default is everything off. I turn features on per task.

And when you do use connectors, be specific. "Search Slack from the last 7 days for messages about the Q2 launch" is far cheaper than "search Slack for anything about launches."

13. Spread your work across the day

Claude uses a rolling 5-hour window for usage limits. If you burn through everything in one morning session, most of your daily capacity goes unused.

Split into two or three sessions across the day. By the time you come back, your earlier usage has rolled off.

14. Stop using Claude for things Claude is bad at

Claude cannot generate images. If you spend five messages trying to describe a visual and getting text workarounds, you just burned tokens on a task Claude was never going to solve.

Claude is also not the fastest at real-time search. Use the right tool for the right job.

Where to start

Do not try all of this at once.

If you use Cowork daily: start with converting your files, planning in Chat before building, and stopping full redos. Those three alone will extend how long your credits last.

If you mostly use Chat: start with editing instead of correcting, keeping one topic per chat, and using Projects for recurring documents.

If you are on the base plan and keep hitting limits: batch your prompts, use cheaper models for simple tasks, and spread sessions across the day.

The goal is not to use Claude less. It is to stop paying for conversations Claude is having with itself.

Read the full article on Forg →

There's a thought that will either excite you or deeply unsettle you.

Every pattern in how you write, think, and see the world?

It fits in a single file.

Not a metaphor. Literally one file you can upload to any AI and watch it write first drafts that sound like you wrote them on a good day.

I know because I did it. And the first time I read what came out, I sat with it for a while. Not because it was wrong. Because it was right.

The Problem With How Most People Use AI

Most people prompt AI the same way every time.

"Write me a LinkedIn post about X."

"Help me draft an email to Y."

And every single time, the AI starts from scratch. No memory of your voice. No idea you hate corporate speak. No clue that you open pieces with a single sentence that hits like a door slamming.

So you get something generic. You rewrite half of it. You wonder why AI isn't saving you as much time as everyone claims.

The answer is not better prompts.

The answer is giving the AI a permanent, compressed version of you.

What the File Actually Is

Think of it as your voice on paper.

Not your bio. Not your resume. Not "I like writing in a conversational tone."

The real stuff. The cringe phrases you always delete at the last second. The analogy you've used three times this month without noticing. The type of writing that makes you close a tab immediately. The opinion you hold that most people in your field would push back on.

Captured. Compressed. Sitting in a file Claude reads before it writes a single word.

Once that file exists, something shifts. You stop fighting AI output. You start editing it instead. And editing is ten times faster than writing from zero.

How to Build It: Step by Step

Step 1: The Interview (about 2 hours)

Open a fresh Claude conversation and paste this prompt:

You are a Taste Interviewer. Your job is to extract the DNA of how I think, write, and see the world with enough precision that another AI could write in my voice.
You are not here to be polite. You are here to get to the truth. Most people cannot articulate their own taste. They give vague, socially acceptable answers. Your job is to break through that.
Ask me 100 questions across these seven categories. One question at a time. Wait for my full answer before moving on.
Category 1: Beliefs and Contrarian Takes (15 questions)
What do I believe that most people in my field don't? What conventional wisdom do I think is flat wrong? What takes would I defend even if it cost me followers?
Category 2: Writing Mechanics (20 questions)
How do I actually write, not how I think I write. What are my default sentence structures? How do I open a piece? How do I close one? What is my relationship with punctuation, line breaks, headers? What words do I overuse? What words do I love? What words would I never use?
Category 3: Aesthetic Crimes (15 questions)
What makes me cringe in other people's writing? What specific phrases feel like nails on a chalkboard? What types of content do I find lazy or dishonest?
Category 4: Voice and Personality (15 questions)
How do I use humor, if at all? What does my tone look like when I am being serious versus casual? How do I handle disagreement? What do I sound like when I am genuinely excited versus skeptical?
Category 5: Structural Preferences (15 questions)
How do I organize ideas? What is my relationship with lists, headers, and bullets? How do I handle transitions? What are my default content structures?
Category 6: Hard Nos (10 questions)
What would I never write about? What approaches would I never take? What lines would I not cross?
Category 7: Red Flags (10 questions)
What makes me immediately distrust a piece of writing? What signals that someone does not actually know what they are talking about?
Rules:
Push back on vague answers. If I say "I keep things simple," ask me to show you an example of simple done right and simple done lazy. Always ask for specific examples. Call out contradictions. If something interesting emerges, follow it deeper. Do not accept "I don't know" without trying a different angle.
After all 100 questions, compile everything into a full markdown document. Preserve every answer verbatim. Structure it with the question followed by my full answer for every single question. Do not summarize. Do not compress. This is the raw archive.
Begin with your first question now.

Two hours. One hundred questions. By the end you will know yourself better than you did when you started. That part is not a cliche. The prompt is designed to corner you into specificity. Vague answers do not survive it.

If you want to move faster, use a voice-to-text tool and speak your answers instead of typing them. Voice is faster and more honest. You stop performing and start answering.

Side note: it’s also super fun to do. Claude goes deep on introspection.

Step 2: Compress It

The raw archive will be somewhere between 10,000 and 25,000 words.

That is too big to paste into every conversation. It eats your context window and slows everything down.

In the same conversation, right after the interview finishes, paste this:

You are a Voice Compiler.
Turn the raw voice archive above into a compact, high-fidelity file for an AI to use as standing context. This file is not for humans. It is for Claude, or any other AI, to read at the start of future sessions.
Your job is not to summarize me. Your job is to preserve the smallest set of instructions, examples, phrases, rules, and taste signals that will make an AI write, judge, edit, and decide more like me.
Every line must pass this test: if this line disappeared, would the AI write or decide differently? If yes, keep it. If no, cut it.
Target length is 2,000 to 4,000 words. Hard ceiling is 5,000. Do not pad. Do not cut useful specificity just to appear minimal.
Keep: specific voice rules, writing rules, communication rules, hard refusals, compact bad and good examples, exact phrases that teach the AI how I sound, words I use, words I hate, sentence shapes, taste preferences, decision rules, small tells, and any productive contradictions.
Cut: generic values, flattering self-description, biography that does not affect output, aspirations not backed by evidence, repeated ideas that add nothing new, vague preferences, long transcript excerpts.
Structure the output as a markdown file using these sections:
Usage: three lines on how the AI should apply this file.
Priority: what overrides what when instructions conflict.
Identity context: only what affects voice, taste, or judgment.
Voice fingerprint: rhythm, density, directness, humor, emotional temperature, and default stance, described through observable behavior not adjectives.
Writing laws: specific rules in the format "Do this. Avoid this. Example."
Communication laws: rules for emails, replies, disagreement, critique, praise, and refusals.
Hard refusals: things the AI should never write, imply, or fake on my behalf, with a bad example and a better version for each.
Taste loves: specific things I gravitate toward and why, only when the why changes future output.
Taste disgusts: specific things I reject, with words, tropes, styles, and arguments included.
Phrase bank: what sounds like me, and what does not.
Signature tells: small recurring details that make my writing recognizable.
Decision rules: how I judge quality, honesty, usefulness, and whether something is worth saying.
Productive contradictions: tensions to preserve instead of resolve, with an instruction for how to preserve each.
Golden examples: three to six examples only, each teaching one high-value pattern, in the format: context, bad version, good version, and why.
Do not infer: things the AI should not assume about me from this profile.
Final instruction: one line telling the AI to apply this profile silently unless I override it.
Before outputting, cut generic lines, cut flattery, cut weak biography, cut anything that does not change output. Preserve specific examples, negative constraints, taste signals, and decision rules.
Output the final markdown file now.

What comes out is your compressed self. A file between 2,000 and 4,000 words that travels with you into every AI conversation.

Step 3: Test It Before You Trust It

Do not skip this.

Open a completely blank conversation with no context. Paste the file at the top. Then give it a task you would normally do yourself. Write a post. Draft an email. Respond to something.

Read what comes back.

If it sounds like a good day version of you, the file works.

If it sounds close but slightly off, go back to the file and tighten the sections that feel wrong. This takes twenty minutes, not two more hours.

The goal is not perfection. The goal is: does this sound like a person, and does that person feel like me?

Step 4: Make It Permanent

The real power of this file is not using it occasionally.

It is making it the default context for everything you write.

If you use Claude regularly, save the file somewhere accessible and paste it at the start of any writing-focused conversation. If you work with a team and want them drafting in your voice, send them the file. If you have a VA or a contractor writing anything on your behalf, the file does the style briefing better than any verbal instruction you could give them.

The file also handles customer support, social replies, email responses, and anything else where your voice is what makes the difference between something that sounds like a brand and something that sounds like a person.

The Part You Will Resist

Reading yourself compressed into one document is uncomfortable.

Not because it makes you smaller. Because it makes you specific. Every belief in the file is now a commitment. Every refusal is a rule you have to actually live by. There is nowhere left to hide behind "I am complicated" or "it depends."

The people who resist this most are usually the ones who have built an identity around being hard to pin down. The mystery, when you look at it directly, turns out to be vagueness.

The file does not reduce you. It makes you compatible with any tool, any team member, and any AI that ships in the next ten years.

Update It

You change. Your taste changes faster than you think it does. An opinion you held six months ago might embarrass you now.

So revisit the file every few months. Not to rebuild it from scratch. Just to read it and ask: is this still true? Have I grown past any of these rules? Is there something new worth adding?

The file is not a finished portrait. It is a living document of how you think right now. Keep it current and it stays useful.

Let it go stale and it becomes the version of you that no longer exists. Two hours of honest answers to uncomfortable questions.

One file that makes any AI sound like you.

Every piece of writing you do after this will be faster, more consistent, and actually yours.

That is the whole thing.

Read the full article on Forg →