Great post, and appreciate what he is saying. But in this case I'm kind of locked into WordPress and the plugins I'm using. It will be much easier to start over with Laravel Spark which will give me more control. From there, I agree that it should never be rewritten again, only refactored.
You can encapsulate your business logic on the WordPress PHP side into PHP classes first.
What you want to do is break your WordPress application into classes containing the business logic and turn WordPress into a dumb wrapper for those classes. At that point, you can move those new classes over to Laravel when you are ready to make the switch.
For example, you can switch your customer dashboard views over to be written in Laravel. You can use either nginx/apache to route, or have a base index.php file that either includes the WordPress index.php or the Laravel index.php based upon PHP code. Within your new Laravel routes, you will be boostrapping WordPress from Laravel and calling WordPress code from within Laravel.
For example the WordPress users. You could create a new class and interface to encapsulate all of the WordPress user code inside your WordPressUser class that implements MyAppUserInterface. Eventually, you will create a new class that implements that interface for Laravel once you are ready to switch out WordPress for user management and use Laravel. With that said, I would likely leave users to be the very last thing you change. And quite possibly, think about leaving WordPress around solely for user auth and management.
The same idea works for posts and other entities you are currently using within WordPress.
On the WordPress side you can implement hooks that can call methods on the Laravel side as you move through the transition.
Rewrites are so often deadly. Please put some serious thought into it. No one knows your business better than you do, so I'll just leave you with that friendly advice.
Also, writing this makes me chuckle as I can't even get a response from a single resume I've sent out over the last two weeks. Sigh...
Have you considered keeping your wordpress as a "frontend" and making API calls to a backend build in laravel? You could slowly migrate your code to a `/v2/` path on the same system. Then, once everything is moved into API calls on the `/v2` path you can just write a new frontend that talks to the new APIs you've built.
I went from startup to corporate and back to startup. You can't resist the desire for instant gratification and feeling of accomplishments that you get at a startup. You become this "T-shaped person", and your knowledge bar on the _T_ keeps expanding because you get the chance to wear many hats, while still being able to expand the vertical bar of your expertise/develop new specialties.
Right on! This freedom to wear many hats is what makes working at startups such a lively place. Startup is chaos and finding ways to contribute to the overall business eliminating the chaos is what makes your worth.
Hiya! Author here. I can't comment on why you felt this was clickbaity. The intention was to give a third-person perspective of the life of an engineer as a webdev at a startup, emphasis on _startup_.
The post is largely targeted at beginners. I think giving this perspective to fresh grads can help them take a decision to atleast clear up the dilemma when they have to choose to work at a startup/corporate during internships or right after college.
The reason I wrote it was because during my four years at college, we had this perception that webdev was boring and nobody used to opt to interview for companies which were into it. And the joke was, "All you do is change the colors every 6 months". I had the chance to intern at a SaaS startup and then worked there for more than 2 years and then figured students back at college needs to know more about this experience.
To debug the process, you can start with searching Google for your own site. The syntax is: "$searchQuery site:wisaw.com", for eg: "wisaw site:wisaw.com"
I got only 4 results with that search. So those 4 pages are definitely indexed. You can check with different search queries for the rest of the pages.
I observe that it's a photo only website. It's hard to get them ranked better than sites with content. Search engines are smarter now, so adding title, description, keywords, etc does not ensure it ranks better for those keywords. It used to work, but not anymore. Search crawler check for actual content and relevance.
Since its "an anonymous photo" app, you'll have to rely high on word of mouth/social/referral traffic instead of organic sources.
I can relate to this. Not a product, but a blog I run gets just ~20 (out of ~200 page views/day) of traffic from HN, Reddit, Facebook, Twitter combined. Rest is organic and most of it is via Google searches.
A bit of a cliche answer, but I'll still go with this: depends on the target audience. Find out who can most benefit our of your product? Developers? Sales? Marketing? General netizen?
Next, figure out where they spend their time on. For eg: to target devs, post on communities like HN (as Show HN). Reach out to community driven blogs and be an author subtly marketing the product. In fact, an interesting story on what you went through during the product building phase, that challenges you solved is exciting enough to intrigue a developer.
General netizen? Share on platforms like reddit (specific subreddit), twitter (would be good if one of your users which high reach can volunteer for this).
Is it a B2B product? Offer the product at a discounted rate to initial users and in return, you can ask for promotion through their site/social media (a bit like testimonials). For eg: I got to know about mixpanel by seeing the badge on the footer of certain website I used.
I read this again now, and I see way too many typos, can't edit it anymore though. Please excuse the messed up grammar and totally unrelated words in between.
Hi! Thanks for the elaborate reply. All great suggestions and will consider what is best for my MVP. If I happen to figure out a great medium I'll let you know!
I think it's meant to be a subtle addition to overall feel when user lands on the page. I've not seen this happen in SaaS products, however, most product marketing/landing pages have a certain "uniqueness" to create a brand/product perception by employing such effects. One of the examples I can think of is Stripe, all the mix of graphics and animations on their product landing pages adds a bit to the overall feel. One other community platform that stands out from design point of view is IndieHackers. Ofcourse, HN has its own charm.
Quite common in early-stage startups, 2-5 people including founders. As soon as the MVP is ready (first 3-6 months usually), they start around organizing things and prioritize stability, robustness over speed of delivery.
If the early engineers were experienced guys, a basic test suite and deployment pipeline would have been the first priority at the onset. It makes releasing frequent commits a breeze. Or else, they learn from subsequent hires to organize code, write tests and add extra processes. If they fail to hire such talent, they learn the hard way, frequent downtimes leading to user frustration and failing to retain them. It's crucial they realize this early on though, otherwise, this could lead to things blowing up pretty quickly leading to the death of the product.
Although I'd say, it sounds unusual for an investment bank. Doesn't sound like a company anyone would stick around for long. Sounds like inexperienced engineering leadership. If you're early in your career, I'd suggest looking for better companies.
