Web developer playing with clouds, LAMP, Symfony, JavaScript. Currently working as a Salesforce developer as part of the Taylor & Hart team.
Kik Minev
01.

Hey there, I'm Kik Minev - web developer playing with clouds, LAMP, Symfony, JavaScript, Salesforce Apex. Currently working as a Salesforce developer as part of the Taylor & Hart team.

Why Salesforce? Pivoted to Salesforce when my colleagues needed a quick and efficient way to optimize business processes, sales and even manufacturing processes. That’s how I stepped into the Salesforce world, though most of my career has been focused on web with PHP. Strong love for the Symfony framework.

02.

My experience

Taylor & Hart - Salesforce and Symfony developer

Currently working as a Salesforce developer at Taylor & Hart where I help with accelerating business processes in sales and manufacturing. I spend my day mostly writing Apex code and lightning components in Salesforce or PHP/Symfony for web features.

Oxxy - CTO

As part of Oxxy I was leading the team as a CTO. We started and shipped a drag and drop website builder that allows small business owners to launch a website without any coding skills. For my tasks I used the Symfony PHP framework, MongoDB, javascript for the web builder and AWS as an ifrastructure.

Webfactory - Web Developer

At Webfactory I spent my days mostly coding with PHP and Javascript. As part of a web agency I worked on various projects for different clients up until I started working on Protect Your Bubble. Really thankful to the colleagues that gave me the chance to work on this project and helped me develop my skills.

Webfactory / Protect Your Bubble - Team Lead

I became responsible for launching the US web site and lead a team of web developers to deliver and support the project. Duties were a bit different as I needed to work in Atlanta and lead the team overseas. Also, working with a Fortune 500 company has it's perks. Thank you all for the warm welcome in Atlanta!

Digitalus - Web Developer

Digitalus was a hosting company from The Netherlands(later aquired by another company). Here we worked with PHP and Javascript.

SiteGround

Epic times! Great start in the web industry.

03.

What I work with?

Back in the days I started coding websites from scratch using PHP and some custom frameworks. Throughout time I worked with ancient frameworks like CakePHP, Zend and others. Nowadays I mostly work with Symfony. Trying to keep an eye on the Javascript world as well.

PHP
Back in time I started with PHP from around version 4. Usually with Apache and MySQL. These days we run mostly nginx.
JavaScript
The beginings was vanilla and jQuery. Later I worked with Backbone and Angular. Now I try to keep in touch mostly with the React framework.
Symfony
I love how robost Symfony is. The initial steep learning curve is paying off with the projects. During the years I've worked with Symfony for SaaS products, CMS and eCommerce systems.
AWS
My experience with the cloud is in AWS where I mostly use EC2 and S3. I also have some experience with RDS for PostgreSQL. During the years I used EC2 to scale Symfony web projects and MongoDB cluster databases.
Git
Git is what I use for version control. Checkout my GitHub. I use Gitflow in my day to day work.
Docker
For personnal projects I will use Docker to maintain my developement environment. In some companies we also worked remotely, in the cloud. In other companies even with k9s on localhost. Depends on the company;)
Salesforce Apex
In Salesforce I usually work with Apex code to develop new features. It shares the Java syntax and object-oriented features, but it's limited by the Salesforce environment.
Ligning Components
Not very often I develop lighning components to extend the Salesforce functionality.
PhpStorm
Though I started with Notepad, moved to Notepad++, Vim, Eclipse, these days I work with PhpStorm and IntelliJ with Illuninated Cloud for Salesforce development.

Back to Basics: Why Fundamentals Still Matter in the Age of AI

Last week I built an upload form for a Symfony project. With AI helping me write the code, the whole thing took a fraction of the time it normally would. A few years ago, this task alone might have eaten a full day. This time, it took me a minutes.

The form worked. It looked clean. It did exactly what it was supposed to do. I was happy.

Then I looked closer.

Underneath the shiny result, there were a few security problems. Nothing that jumped out at first glance. The kind of thing you only catch if you know what to look for. If I did not have years of experience building web apps, I probably would have shipped it as is.

That thought stuck with me.

Speed Is Not the Same as Safety

AI tools are incredible at helping us move fast. They write working code in seconds. They handle boring, repetitive tasks so we can focus on bigger problems. This is a real gain, and I do not want to pretend otherwise.

But speed hides a trap. A form, a login page, or a file upload can look perfect on the surface and still have holes underneath. The code runs. The tests pass. The client is happy. And none of that tells you whether the app is actually safe.

This is fine if you are experimenting on a side project. Nobody gets hurt if a hobby site has a bug. But if you are building something for a real business, with real customers and real data, those small gaps can turn into a big problem. A single unsafe form can lead to lost data, stolen accounts, or worse.

Why Basics Matter More, Not Less

There is a strange effect happening right now. As AI writes more of our code, understanding the fundamentals of web development becomes more important, not less.

When you did everything by hand, you were forced to think through each piece. Now, a tool can write a form, a login flow, or an API endpoint before you have even finished reading the requirements. That is powerful. But if you do not understand what is happening under the hood, you cannot tell good code from risky code. You are just trusting that it is fine.

Experience is what lets you spot the difference. It is what makes you pause and ask, “wait, what happens if someone sends bad data here?” or “can anyone else access this file?” AI will not always ask those questions for you.

What I Am Doing About It

I want to help close that gap a little bit. Starting soon, I will be writing a series of blog posts about basic web security. Simple explanations, no heavy jargon, aimed at anyone building on the web today, whether by hand or with AI as a partner.

We will cover things like:

  • CSRF attacks, and why a form without protection can be tricked into doing things the user never intended
  • Cross origin attacks, and why your browser’s rules around this actually matter
  • Other common weak spots that show up again and again in real projects

The goal is simple. If you are building something for yourself, have fun and experiment freely. But if you are building something for a business, a little bit of knowledge about these basics can save you from a very bad day later.

AI is a great tool. It just does not replace understanding what you are building. Sometimes going back to basics is exactly what moving forward requires.

Leave a Reply

Your email address will not be published. Required fields are marked *