From code snippets to reusable cloud functions

The origin

A small experiment that outgrew its premise

I wanted to build something useful, relatively simple, and potentially capable of generating passive revenue. Tools like Pastebin get significant traffic, so the initial concept was straightforward: a more modern way to quickly share code and text, supported by advertising and paid features.

I designed and built an MVP around that idea — public and private snippets, expiration, password protection, burn-after-view sharing, syntax highlighting, and support for a broad range of programming languages.

But the more I explored the space, the clearer the limitation became. Snippet sharing was useful, but it wasn't particularly differentiated — plenty of products already solved the same problem.

The more interesting question became: what could a snippet become if it didn't have to remain a static piece of code?

Moving beyond snippets

From something you copy to something you can use

Developers constantly rewrite, copy, and adapt common pieces of functionality — a small utility for transforming JSON, formatting dates, validating data, or calling an API.

Instead of requiring another developer to copy that code into their own application, Snipdrop could turn it into a reusable cloud function: write it once, define its inputs and outputs, publish it, and let other applications invoke it as a service.

The progression was natural — snippet → reusable function → shared dependency → workflow. Rather than another place to store code examples, Snipdrop could become an integration layer for reusable functionality.

Functions as a service

Build once. Use anywhere.

The Function-as-a-Service concept let developers package common or specialized functionality behind a simple interface — normalize an address, reformat a dataset, generate an image, analyze text, or run a difficult calculation.

Another developer wouldn't need to understand or recreate the implementation. They could provide the inputs and consume the result. Functions could also be connected into workflows, where the output of one becomes the input of the next.

That opened up a much larger opportunity than snippet sharing alone — especially as AI made software easier to create while increasing demand for reusable integrations, tools, and services.

Community as infrastructure

Let developers build for other developers

The next part of the concept was a community marketplace, modeled in part after ecosystems like the Figma Community and plugin marketplaces.

Developers could publish functions for others to discover and use — simple utilities offered publicly, or highly specialized functionality sold as a service. It created a way to earn from work already done, while letting others avoid rebuilding the same solutions.

Instead of Snipdrop owning every integration, the community could expand the platform itself.

Shared datasets

Functions are more useful when the data is already there

Reusable functions often depend on reusable data — postal codes, geographic boundaries, weather, location data, or public records. That data isn't always easy to source, normalize, or maintain.

So the community concept extended beyond functions to datasets developers could publish and maintain. A dataset could be valuable on its own or used as an input to community functions and workflows.

Data provides context. Functions provide capability. Workflows combine the two.

Designing the platform

From utility to ecosystem

I designed the broader Snipdrop experience around that evolution. The original snippet product established the fundamentals — creation, sharing, permissions, privacy, and discovery.

From there it expanded into function creation and execution, workflows, community discovery, reusable datasets, and a marketplace where developers could share or monetize what they built.

The design challenge shifted accordingly. Instead of a single-purpose utility, I was designing how developers create resources, understand dependencies, configure inputs and outputs, discover community content, reuse another developer's work, and combine those pieces into larger systems.

What I built

Built vs. designed

The snippet-sharing product was implemented as a working MVP. The broader Function-as-a-Service platform remained a product and design exploration rather than a production system.

That distinction became part of the point. Building the MVP exposed the limits of the original business idea — so instead of piling incremental features onto an already crowded category, I used it as a foundation for exploring where the concept could create substantially more value.

Snipdrop became an exercise in zero-to-one product thinking: identify a market, build a primitive, recognize its limits, and evolve the concept into something more defensible.