About
An engineer who took the visual builder seriously
Webflow is a fine tool and a bad excuse. Treated like a codebase, with named components and a real content model, it holds up for years. Treated like a canvas, it becomes somebody else's problem in eighteen months.
01/Background
Ten years of building for other people
I am Shreyas Kothakonda, a Webflow Certified Partner and software engineer. I build marketing sites and product frontends for teams who need the result to be fast, editable and still standing in two years.
Most of my work sits in an awkward gap the industry likes to ignore. Design studios build sites that look right and fall apart the first time a client edits them. Engineering teams build systems that hold up but take a sprint to change a headline. I spend my time in between: Webflow builds with real engineering underneath, and coded frontends built with the taste of someone who cares what the thing looks like.
I came to it from the code side. Years of hand-building sites, then agency front-end work, then two years inside a product team maintaining interfaces long enough to learn what shortcuts actually cost. That is the perspective I bring to a visual builder: treat it like a codebase, name things properly, and assume somebody else will inherit it.
The best compliment I get is silence. Nobody emails to say the site is still fast, but they would absolutely email if it were not.
02/How I work
Six stages, in this order, every time
The order matters more than the list. Most failed builds I have inherited went wrong in stage two and did not find out until stage five.
- 01
Scope and audit
I start with what exists. Current analytics, the pages that actually earn traffic, the workflows your team is stuck with. If we are replacing something, I want the redirect map and the content inventory before anyone opens a design tool.
- 02
Content model
Before layout, we agree what the site is made of: which things are collections, which fields they carry, and who edits them. Getting this wrong is the single most expensive mistake in a build, and it is almost always made in week one.
- 03
Design translation
I read the design file properly, agree the type scale, spacing steps and breakpoints, and flag anything that will not survive real content. Questions asked here cost minutes. The same questions asked during build cost days.
- 04
Build and integrate
Components first, pages second. Integrations are wired with their failure states built at the same time as their success states, because the version that breaks is the one your customers will eventually see.
- 05
Performance and accessibility pass
Every template gets audited before launch, not after a complaint. Keyboard paths, focus order, contrast, heading structure, image weight, script budget. Findings get fixed in the build rather than logged for later.
- 06
Handover and training
A recorded walkthrough, written notes on the class system and CMS structure, and a working session with whoever will run the site. Then a check-in at thirty and ninety days to catch what drifted.
03/Education and credentials
Where the foundations came from
A certificate proves someone checked. The reason it matters here is what sits underneath it.
Webflow Certified Partner
Webflow
Assessed on build quality, CMS architecture and client delivery against the platform's own standards.
Current
B.Tech, Computer Science and Engineering
University coursework
Data structures, algorithms, databases and software engineering practice. The foundation under everything that is not visual.
Completed
Web accessibility, WCAG 2.2 AA
Self-directed study and applied practice
Working knowledge of success criteria, ARIA patterns and assistive technology testing, applied on every build rather than kept as theory.
Ongoing
Core Web Vitals and technical SEO
Applied practice
Field and lab performance measurement, crawl and index diagnosis, structured data and migration planning.
Ongoing
04/Principles
The rules I will not quietly drop under deadline
Every one of these exists because breaking it cost somebody real money, usually me.
01
The handover is part of the build
A site your team cannot edit is a site you will pay to change forever. Documentation and training are scoped in from the start, never treated as an optional extra at the end.
02
Measure before opinions
Performance and SEO work starts with numbers from your actual pages. I would rather show you a slow trace than tell you what usually causes slowness.
03
Accessible by default, not by request
Keyboard access, focus visibility, labelled controls and AA contrast are build requirements. Nobody should have to file a ticket to use your website.
04
Name things as if someone else is reading
Classes, components and CMS fields get names that make sense to the next person. Clever shorthand saves me a minute and costs your team a week.
05
Say what will not work
If a requirement fights the platform, or a deadline needs scope removed, you hear it early. An uncomfortable conversation in week one beats a missed launch in week six.
06
Build the failure state first
Loading, empty and error states are designed alongside the happy path. The interface should never leave someone staring at a spinner wondering what went wrong.
Taking on two new builds per month
Have a build that needs to be fast, editable and correct?
Tell me the scope, the deadline and what has gone wrong before. You will get a straight answer on whether I am the right person for it, usually within a business day.
- shreyas@example.com
- Phone
- +1 (000) 000-0000