Non-technical guide to getting your green dots on GitHub

One thing I have learned from years of working at software companies on the non-technical side is that engineering resources are finite. Small requests can take a while to get to, and more importantly, they are often not the best use of an engineer's time.

When I started at tldraw, a lot of data lived in many different places, and often the same data lived in several of them. One of the biggest challenges in ramping up was simply being able to interact with that information in a fast, scalable, and UI-friendly way.

For example, all I wanted to do was look at one of our internal dashboards without having to sift through a long list of personal email addresses, like Gmail, Yahoo, and others. So I asked our Head of Engineering to see if he could add a way to hide personal email addresses from the view.

We get a lot of inbound interest in the tldraw SDK, but a healthy amount of it comes from hobbyists and tinkerers. We absolutely support those folks too, and you can apply for a hobby license here, but my job on the go-to-market team is to help companies build with tldraw and, ideally, pay us. To ask people if they'd like to pay us, I needed their emails. But our Head of Engineering had better things to do.

This is where “vibe coding” came in. Instead of waiting, I could just ask my AI to make the change for me.

That solved one problem and immediately created another: how do I go from “robot, fix this” to code that is actually usable across an organization?

If, like me, you're a non-technical employee trying to get your code into the repo,

here's everything I've learned about Git, PRs, merges, keeping branches up to date, code review, deployment, and all the other things the technical side of the house seems to know instinctively.

Okay, I built something. How do I actually get people at my company to use it?

You opened Codex, built an application, and it seems to work. Great. Now comes the part that was much less obvious to me: how does something go from working on my computer to being a real piece of software my teammates can use?

How do I know this thing actually works?

It works when I click around in it, but how do I properly test it? What should I be testing beyond the most obvious way to use the tool? Can Codex write those tests for me? And how do I know the tests it wrote are actually good enough?

The short answer: Have your coding agent create automated tests for the important things your application does, then actually try to break it yourself. Test bad inputs, refresh the page halfway through something, open it in another browser, and do the things a normal user will inevitably do. You are trying to get from “it worked for me once” to “I have some confidence it will keep working.”

The app works locally, where does the code go now?

I have a folder full of code on my computer. Presumably that is not where the final version should live. Do I create a GitHub repository? Does my company already have a place for projects like this? Can I create one myself?

The short answer: For most companies, the next stop is a repository in the company's GitHub organization. This gives the code a permanent home, keeps a history of changes, and lets others review and contribute to it.

Okay, it's in GitHub. How does someone review it?

Do I just send an engineer the repo? Do I open a pull request? What exactly am I asking them to look for? And am I asking them to review whether the application is good, whether the code is good, or both?

The short answer: This is where your company's existing engineering process becomes useful. Rather than inventing your own process, ask an engineer how code normally gets reviewed and follow that. Your first review will probably uncover things Codex had no way of knowing about your company's systems, standards, and security requirements.

The code is approved. Where does the actual application live?

GitHub holds my code, but that's obviously not the application my coworkers are going to open. Where do our internal applications run? Do we use AWS? Vercel? Some internal platform? Who actually puts it there?

The short answer: This is deployment. Most companies already have an approved place and process for running software. You probably do not need to understand or build that infrastructure yourself. You need to find out what your company uses and how your application gets onto it.

How do people sign in?

I definitely don't want to create a separate username and password system for the thing I just built. Can people sign in with their normal work account? Can I make it available only to employees? Or only to my team?

The short answer: Ideally, you plug into whatever identity system your company already uses, whether that's Google, Okta, Microsoft, or something else. This gives people access with their existing company identity and lets the company control who can use the application.

How does the app get access to everything it needs?

My local version might be using an API key I gave Codex, or credentials sitting on my computer. What happens when the application is running somewhere else? How does it securely connect to Salesforce, Slack, OpenAI, our database, or whatever else it needs?

The short answer: Those credentials should not live in your code. Companies generally have a way to securely store secrets and give applications access to other systems. This is also the point where you need to understand what data your application can access and what permissions it actually needs.

How do my teammates get access?

Once it's deployed, do I just send everyone a URL? Is there an internal directory of applications? Do they need permission first? What happens when someone joins or leaves the company?

The short answer: This depends on your company's setup, but ideally access is tied to the same identity and permissions systems the company already uses. The goal is for access to behave like any other internal tool, rather than becoming something you manually manage.

How do I make sure it behaves like a real application?

If I save something and come back tomorrow, is it still there? If my teammate changes something, do I see their change? If two people use it at the same time, does it work? If I refresh the page, does everything disappear?

The short answer: This is the jump from a working interface to a working application. You need to think about where data is stored, what happens when multiple people use it, and what should persist between sessions. Your coding agent can build a lot of this, but you need to tell it what behavior you actually expect.

What happens when I want to change something?

The first version is live and then, inevitably, I want to add something the next day. Do I go back into Codex and start changing the code? How do those changes get from my computer into the version everyone is using without breaking it?

The short answer: You repeat the same loop: make the change, test it, push it to GitHub, get it reviewed, and deploy it. Once that loop exists, shipping the second version should be much easier than shipping the first.

How do I know if I broke it?

If someone messages me saying “your thing isn't working,” what do I do? Can I see errors somewhere? Can I see what happened? Is there a way to know it's broken before someone tells me?

The short answer: Your application should have some basic logging and monitoring. You don't need a sophisticated system for your first internal tool, but you do need somewhere to look when something goes wrong.

At what point is this actually a company application?

If ten people start using it every day, who owns it? Am I responsible for maintaining it forever? What happens if I change jobs? When should an engineering team take responsibility for it?

The short answer: There probably isn't one universal answer. But once other people depend on something to do their jobs, ownership becomes just as important as whether the code works. Someone needs to know how it works, how to change it, and what to do when it breaks.

Next steps

Ideally, once you have most of these steps down, you can start actually “shipping”. That's when the things you build stop being experiments on your laptop and make it into production as tools people actually use.

For me, that has probably been the most rewarding part of learning all of this. The GTM team has now shipped a meaningful amount of product ourselves, from relatively simple improvements like filtering inbound leads by business vs. personal email, to much more substantial projects like the internal contract generator we built. And that does not even touch some of the outbound tooling and internal workflows we have built along the way.

I won't pretend to know exactly where all of this goes, but I am incredibly excited about what it means for teams like ours. There is a huge amount of work inside every company that is too specific to justify dedicated engineering resources, but still creates real friction every single day. Giving the people who experience those problems firsthand the ability to build and ship their own solutions feels like a meaningful change in how teams can operate.

We’d love your feedback. Get in touch with us on our Discord or follow us on X. If you'd like to put a canvas like this in your own product, check out our docs or starter kits.