wrote about my experience making my first app
& how approaching software as a creative practice completely changed my perspective https://x.com/i/article/2110500083481321472
Art and software are more similar than you think
On my first day at Danger Testing, @itsjessyin asked me what app I was going to drop that week. I laughed. Drop an app? No – that’s not what I’m here for. I don’t do that.
I spent the past year working on “AI for everyone” at @dreamer and @muse, but I was still stubborn that app creation was the exclusive domain of 1) artsy software engineers and 2) creators who are great at navigating Figma files. Since I’ve never actually written a full software project by hand and know zero Figma shortcuts, I was clearly unqualified.
I was also too nervous to try, because the thought of making an ugly app in my first week at a company full of people I admired made me cringe viscerally. My previous attempts, while well intentioned, didn’t look that great.
Unfortunately, having an idea for an artistic pursuit is an all-consuming desire that’s difficult to shake. When an idea strikes, I must create! Lo and behold, inspiration hit one evening, and I had an app idea I couldn’t get out of my head.
The only way out was through: I had to make the damn thing. I had to build the app, and make it look compelling enough that presenting it to my new, talented team didn’t make them question hiring me.
The following chronicles 3 lessons I learned in the 48 hours of building my first ‘official’ app, Tech or Fashion, a game where you guess if the outfit pictured was worn by a tech bro or a NYFW model. While these lessons may seem rudimentary to the highbrow creative technologist, I document them below for the person I was just a few weeks ago: someone who needed a bit of encouragement and reframing to embark on their first software project.
Psst - this article was originally published on the @dangertesting blog. Subscribe to read more pieces like these.
Lesson #1: The rules of structured artistic practice apply to software, too
Naively, I thought not having to write code meant not having to think about it much either. My conception of app building was:
1. Have a genius idea
1. Tell Codex 3 sentences about it
1. Bask in my creative glory
I quickly learned it doesn’t work that way. Here’s the first output I got when I tried the “slop it down and cross my fingers” method:
Yikes – this is not exactly what I had envisioned in my head. The output looked like complete slop, and I was tempted to give up and rule myself out of the creative class.
As it turns out, I was missing an important framing. If creating software is akin to making art, we should begin where artists do: not with the tools, but with a plan. Painters sketch; writers draft; directors storyboard; software creatives must plan too.
The Conjuring director James Wan notes in an interview that “there’s nothing worse for a film crew and a production [than] a director that is not prepared. It’s horrible. If they don’t know what they want, don’t know how to achieve it, that’s really draining on a production.”
Coming ill-prepared to Codex is the same: you are the director of the software, and if you’re not prepared, you’re going to waste your time, a lot of tokens, and the creative enthusiasm you initially had.
I had to take a step back and figure out how to translate the fleeting seed of an idea into something tangible and structured. Structured did not mean complicated; I sketched a simple wireframe onto paper, opened Photobooth, and sent it to my agent.
Iterating on this a few times drastically improved how my app looked and felt. The early versions were still mediocre, but this bit of structure gave me a clearer sense of what I wanted, and gave my agent something tangible to work toward. From there, it became a process of adding, subtracting, and refining features.
Wireframing, prototyping, and architectural design are longstanding app-building practices, but the people that I envision will be building the most creative software have never taken a CS class before. A SWE’s memories of CS61A at UC Berkeley will not be readily accessible to most people. Even though I took a handful of engineering courses myself, this planning process still didn’t click until after I built my first app.
Play is integral to creation, but artistic freedom comes from learning how to wield your tools. The spontaneity of play is enabled by years of honing your craft. To get to the level where I can build a great app with no rules, I must get a hold of the basics first.
Lesson #2: Tools can’t execute your vision for you
A camera can capture a photo for you, but it cannot make it beautiful. You still need to position the frame in a way that turns your amorphous vision into a tangible output.
Software is the same. Coding models will help you code, and they can prod at your creative ideas, but they will not bring your vision to life on their own.
I realized I had to find visual inspiration and references that best articulated the creative vision in my head for my app.
I took a note from Marc’s lessons to embrace sampling. I drew inspiration for the look and feel of the app from SSENSE, and explored ways to make the citations convey the same concise authority as Wikipedia’s visual references.
You can see the inspiration from these references pretty clearly in the final app:
Life hack: Visual references from websites you love help a lot, as most websites are already optimized to be great software experiences. This is not to say your software can’t (or shouldn’t) be inspired by life outside the web!
Lesson #3: Keep the fun stuff for yourself
This particular app required identifying 20 outfits tech bros and NYFW models have worn. I started by asking Codex to search the web for these outfits and return the results.
As Codex started sharing images of NYFW outfits, I got bummed – I wanted to look through these outfits! In my pursuit of efficiency, I made myself jealous of a task I told my agent to do.
I ended up searching around and handpicking the images myself, which better encompassed my voice in this project as well. This moment was a great reminder that coding agents are merely tools; I am ultimately in charge of how I triage my creative process, and should preserve the parts that excite me the most.
This first app was a turning point after many months of partial attempts, quitting early, and wishing I could be a creative person. I have a screenshot of Link Bouquet from this past March, before I even met @marcgmbh and @downloadlos, or knew what Danger Testing was.
I stumbled across it online and saved it as inspiration, hoping that one day I could make software that felt just as fun and exciting
As it turns out, it was never a question of ability, just perspective. Reframing software creation as an artistic practice frees the mind; you can optimize for things beyond users, engagement, or scale. In my case, success meant giving a clear visual form to one pressing cultural question: “Do software bros have taste now?”
https://x.com/slopfactorytv/status/2108233610742603788?s=20
Hell, you don’t even need to optimize for anything. Software was once too expensive to make without a practical purpose; now, it can be a medium for experimentation, self-expression, and play. We can now treat coding like art, and make something simply because we want it to exist.
Following a process won’t immediately make it great, but it’s what moved me from watching other people make things to creating myself.
Thank you to @itsjessyin and @downloadlos for editing this article, and to the entire @dangertesting team for encouraging me to make my first app of many.