YC Backed Pagedraw Automates Front-end Web Development

Full-stack developers constantly have to translate mockups from designers into HTML and CSS. Not only can translation be repetitive and mechanical, it can be time-consuming. Founded by Harvard grads Jared Pochtar and Gabriel Guimaraes, Pagedraw automatically translates mockups into frontend, React code using compiler-like architecture.

YC Backed Pagedraw Automates Front-end Web Development

Kailash Sundaram | June 29, 2018

Full-stack developers constantly have to translate mockups from designers into HTML and CSS. Not only can translation be repetitive and mechanical, it can be time-consuming.

Founded by Harvard grads Jared Pochtar and Gabriel Guimaraes, Pagedraw automatically translates mockups into frontend, React code using compiler-like architecture. Pagedraw allows users to stress-test designs and automatically imports generated code to GitHub. Unlike other WYSIWIG editors, Pagedraw reflows correctly with dynamic data, syncs with other tools designers use, and generates semantic flexbox code. The platform officially launched in February of 2018.

Pagedraw also participated in Y Combinator’s Winter 2018 batch and has been backed by Lightspeed Venture Partners, the co-founder of Quora, and football legend Joe Montana. We spoke with Pochtar and Guimaraes about how Pagedraw is redefining the software engineering experience.


What was your initial inspiration for PageDraw? 

As an engineer at Dropbox, I realized the burden of having to translate a design into something that could be presented to the end user. One day, while I was working on a product, a designer tapped me on the shoulder and said, “Hey Jared, I actually need more drop shadow on this toolbar button.” The designer was right that the toolbar could look better, but I didn’t want to be the one to do it. I was working on my own unrelated part of the project, and now I’d have to dig into some CSS to make small tweaks. I found this to be a ridiculous waste of my time.

I felt that a computer could do the same work I was asked to do because the designer handed me a computer file. It’s not like she drew a sketch on a napkin. She used a program called Sketch, a standard designer tool. Being able to turn mockups into functional UI code would alleviate a burden for engineers.


Can you walk me through your founding team’s background leading up to PageDraw?

I began programming at a young age and developed a particular interest in compilers. At 17, I took a graduate-level systems course at Columbia University, where I developed a close relationship with the professor. I eventually served as his teaching assistant, did some cool compiler research with him, and became the youngest-ever intern at Palantir, where I worked before matriculating at Harvard. During college summers, I worked at DropBox and Patreon.

I met Gabriel at a Harvard meetup for students interested in programming before we both entered Harvard. Before co-founding PageDraw, Gabriel worked at Google on their Linux Core Internal Team on Docker Checkpoint Restore. That’s a lot of buzzwords, but it basically means Gabriel worked on the hardest technical problems.

I recruited Gabriel to work on PageDraw with me because of his backend expertise. The best performance engineers often come from a systems background. Gabriel immediately understood the problem we were trying to solve and why it was both interesting and difficult.

What does your team bring to the table that makes you especially capable of solving this problem?

Our product is a compiler that turns designs into code, so my background in compilers has been especially important to get to the product we have today. Gabriel has a lot more background in teaching and interacting with developers – our target audience – and he’s also extremely technically savvy. Pagedraw has a lot of very hard technical problems so it was important that the whole founding team brought some technical expertise to the table.


Why have other efforts to solve this problem in the past failed?

Programmers have been trying for decades to find a way to intuitively build web applications. While web development programs like DreamWeaver have sort of tackled the problem, they have failed to solve the problem once and for all. Their flaw is that they operate as shortcuts and frameworks, not as tools.

The problem with web development in general is that it was designed to handle documents and not applications. The model behind HTML is fundamentally a different mental model than the one designers have. A user or a designer might think along the lines of, “I want to put this button here, this rectangle here.” But that’s not how HTML works. HTML works by saying “I have this column of stuff and the more I add to it, the more I’ll keep adding and adding and adding.”  It doesn’t subdivide space the way we do.

The Pagedraw interface

Past solutions and developer tools always tried to address this problem in one of two ways: (1) they imposed the computer’s mental model on the designer or (2) they imposed the designer’s mental model on the computer. It doesn’t quite work, either way. If you take the designer’s mental model and impose that on the computer, you typically end up with strange and hard to find bugs. Pages, for example, might not resize correctly.

On the other hand, if you impose the computer’s mental model on the designer, you typically get really wonky tools that feel less natural than just typing code. Most people give up on these tools because they prefer the familiarity of dealing with the underlying code themselves.

How does your technology deal with the fact that the designer and computer have different thought models?

We let designers use whatever mental model they like, and let our technology resolve the differences between their thought model and the computer’s thought model. You can try our technology directly through this basic design interface.

PageDraw is also compatible with existing design tools like Sketch, and we let users import directly from these tools if they so choose. We translate these design-specifying files directly into responsive code.

Essentially, we function like a compiler, translating one type of code to another type of code. We’re now using Gabriel’s systems expertise to work out the kinks in web development so we can really get PageDraw right.

Who are your competitors in this space, and what is your edge over them?

Pagedraw’s main “competition” is the current workflow. Designers today work in Photoshop, Sketch, or some other tool, and give their mockups to frontend engineers. These engineers then create the frontend from scratch in HTML, CSS, or React. Pagedraw almost entirely eliminates this workflow. Designers would simply create mockups on Pagedraw, which would then translate these mockups into frontend.

Other players in this space focus on different areas of the market. Wix and Squarespace, for example, help individuals create static landing pages. That’s not what we’re going after.

How do you size your target market and revenue opportunity?

13% of all developer work worldwide is automatable through PageDraw either now or in the short-to-medium term as the product evolves. There are around 3 million professional developers earning an average of $100,000.00 per year in the United States alone. If we charge companies one quarter of the value we create, we get to a 10 billion annual recurring revenue opportunity with near 0 marginal cost.

How do you generate revenue?  Tell us a little about your business model.

We plan to have the same revenue model as GitHub, which nailed the pricing mechanism for develop tools. Out platform will be free for individuals, who would normally not be able to afford PageDraw but could get a lot out of the tool. We plan to charge enterprises, who get a lot of value out of us and make money off of that, on a monthly subscription basis. The cost will depend on the size of the company, the size of the team, and individual use cases.  


How much traction are you seeing among customers? Any particularly insightful feedback?  

We’re already launched internally to YC companies. Some companies have been using us for months now, and we’ve been gradually rolling out to more and more YC companies.  After watching these YC companies use Pagedraw we feel like now is a good time to officially launch given that we’ve been able to support the diverse needs of our current users pretty well.

Do you have any major development goals moving forward?

We’re in a phase where we’re trying to grow our team.  We had our first hire, Michael, join us about six months ago, and we just recently made our second hire, Elizabeth.

What is your long-term objective with PageDraw, and what do you see as your greatest hurdles to achieving this?

Our long-term mission is to make programming more powerful and efficient by eliminating the need for HTML or CSS. Unlike most companies, our goal is to not only accelerate a single area, like fintech or agriculture, but technology itself.

The greatest hurdle to replacing HTML and CSS is getting every developer to use Pagedraw. The way we plan to do that is by pitching to developers that we not only save them time or energy, but we also improve their code quality. When developers hand-code in assembly language, their systems are much more complicated than they need to be, and as a result, have far more bugs. Our compiler improves code quality and reduces bugs.

Message you would like to convey to our readers?

No company has owned the development space since Microsoft in the 90s. Back then, everyone was on the Windows platform. Microsoft defined programming.

We at Pagedraw want to define what programming is and what it should be.

Share This Post